cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gerard van Enk" <gerard.van....@eo.nl>
Subject RE: [RT] latest wonderings around W3C land and surroundings
Date Wed, 29 Mar 2000 21:15:45 GMT
> 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.

> ------------- 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.....

>
> -------- 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?

>
> 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?????

Gerard


Mime
View raw message