cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] latest wonderings around W3C land and surroundings
Date Wed, 29 Mar 2000 22:07:02 GMT
Gerard van Enk wrote:
> > welcome to a new episode of [RT] (random thoughts from Stefano's damaged
> > synapses) sponsored by ... (send big bucks to place your company's logo
> > here! :)
> >
> Finally a new episode......
> > ----------- XBase ----------------
> >
> > xbase is a simple way to make it possible for xml-handlers to know the
> > base URI of that document. At first, it looks like Cocoon _should_ be
> > able to use that information in order to locate URIs. The question is:
> > does XBase violate concern separation?
> >
> > think about it: if you have xbase:base="http://myhost/mypath/" in your
> > document, how are you going to move it around?
> >
> > Hmmm, makes me think that XBase is good on client side, but on server
> > side sucks.
> >
> I agree, but in the future it will be used, also on the server side. Think
> about a xml-file which contains a lof of links. Because people are lazy
> (isn't this the only reason basehref in html was invented;-)) they will use
> XBase. That's the reason why I think the link translating mechanism for the
> sitemap should be aware of XBase.

Another good point. We'll add support for XBase.
> > ------------- XInclude -------------
> >
> > Is XInclude enough for what Cocoon needs about internal subrequests? I
> > don't know. XInclude is somewhat neutral on what side it's using and
> > after putting it more thoughts, I don't think that something like
> >
> >  <xinclude:include href="..." user-agent="mozilla">
> >
> > is good. On client side, of course, this is bad, but even on server
> > side, I think that different behavior should be associated to URI on the
> > sitemap rather than on different HTTP headers.
> >
> +1. This will be done by a matcher tag in the sitemap, isn't? But this
> matcher isn't implemented yet, or did I miss it?

> > ----------- XLink -----------------
> >
> > The question is: how do we perform such transformation? Should there be
> > a sort of "stylesheet" for links? should this information be contained
> > in the sitemap? if so, how?
> >
> If it's possible, I think it must be done with information in the sitemap,
> because this is something for the person who writes the sitemap (structure
> of the site)....But I don't know how this can be done.....Or, as I think
> about it, maybe it's better to use a combination of information in the
> sitemap an a stylesheet.....
> > and even more important: is the idea of "soft" links good as it sounds
> > appealing? or hides trouble by adding another abstraction to remove the
> > URI-space contracts between site management and document writers? Should
> > those URI contracts be enforced rather than weaken up like this?
> How can a person who didn't write the document, take care of the link
> translation? This person has to know where the resources are that are linked
> in the document....And if he has to ask the documentwriter about this, the
> document writer also knows the links, or I'm I talking nonsense?
> I don't think this contract can be removed.....

I tend to agree, but I'm still not sure...

> >
> > -------- SMIL ---------------
> >
> > should we process this as well on the server side? heard people talking
> > about MPEG2 serializer for Cocoon to be able to use Cocoon as sky-link
> > driver for satellite set-top boxes.
> >
> What does this MPEG2 serializer do?

it _would_ create a browsable MPEG2 stream that you send to your settop
box thru a satellite link so that you can _publish_ web sites on your TV

Think about something like this

 TV <- box <-(mpeg2)- satellite <- gateway <-> cocoon
  |                                  ^
  +--> phone ------------------------+

where the "gateway" is something that translates proprietary or MPEG
specific protocols, into some request that cocoon can understand, then
adapt cocoon response to the output stream.

the MPEG2 serializer would generate the up-stream payload, depending on
user input.

DISCLAIMER: this is WILD! and I'm not even going to plan to touch
something like this... but in theory it is possible to make Cocoon do
the publishing even for stream-based digital broadcasting systems based
on XML files. Many times, publishing is one way only (push) like for
indexes, or program information, or even for box code remote upload.
Some of this could easily be published by Cocoon, given an output
channel to the box.

> > But it's not impossible to think about some wild video capabilities on
> > the server side that require server processing (and tons of processing
> > power and bandwidth)... I know, still to early for this thing but, hey,
> > these are [RT]!
> >
> I like the idea of adding support for SMIL to Cocoon, but I don't know what
> kind of support this will be, can somebody give an example?
> > Ok, enough for tonight. Stay tuned for a new episode of "[RT]" :)
> >
> > taa, da da daa, ta da daaa (startrek NG tune fading away...)
> >
> Will there be as many RT-episodes as there are Startrek-episodes?????

Nahh :)

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------

View raw message