cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject [RT] latest wonderings around W3C land and surroundings
Date Wed, 29 Mar 2000 00:23:14 GMT
Ok people,

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! :)

This time I'll express my personal opinions to what the W3C is doing and
why this means to us.

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

------------- XInclude -------------

xinclude is now rated WD so we are expecting to see it emerging as a
stardard and this is good. I like XInclude. It's simple and
straightforward. Some example are given below (taken from the spec)

<?xml version='1.0'?>
<document xmlns:xinclude="">
 <p>120Mz is adequate for an average home user.</p>
 <xinclude:include href="disclaimer.xml"/>

<?xml version='1.0'?>
 <p>The opinions represented herein represent those of the individual
 and should not be interpreted as official policy endorsed by this
 <p>Copyright &169; <xinclude:include href="year.txt" parse="text"/>


which is _much_ better than using external entities and much easier to

Should Cocoon support this? definately yes! 

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.

So, yeah, basically I think that XInclude is all we need for internal
subrequest, of course, considering that we pass on all the http
parameters received on the first request... alsmost like Servlet 2.1

----------- XLink -----------------

XLink is another good spec but was mainly created for client side: all
Xlinks are today _hard_ in the sense that they provide "behavior" for
links but never touch the URI. This is, of course, _required_ at client

On server side, on the other hand, there could be the need for document
writers (which are in control of the links) to linke together "files"
rather than "resources", because they write the files but they don't
know (nor should know!) where those files will end up being on the site
URI space.

For example

<document xmlns:xlink="...">
 <p xlink:href="guide.xml">User Guide</p>
 <p xlink:href="faq.xml">FAQ</p>

might need to get placed to 


so, whatever performs the server side transformation must apply the link
transformations. Such links are called (by me) "soft". And while the
XLink specification doesn't take those links into consideration so
doesn't provide semantics for such a thing, there is a way to do it
using the link "role"

So, again

<document xmlns:xlink="...">
 <p xlink:href="guide.xml" xlink:role="soft">User Guide</p>
 <p xlink:href="faq.xml" xlink:role="soft">FAQ</p>
 <p xlink:href="" xlink:role="hard">Apache</p>

which would indicate that the third link should _not_ be transformed.
NOTE: "soft" links and "relative" links have nothing in common. One
could have soft links both relative and absolute, and relative links
both soft and hard.

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?

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?

I'm still looking for answers, but while I think it's a good practice to
use hard links where possible, I believe (from experience with
stylebook) that is not possible to go along without, without totally
breaking web-app portability (as with XBase for the single document).

------- XSchema ------------

getting very complex, but namespace validation is something that we need
like fresh air... can't wait to throw DTDs down the drain... Anyway,
we'll get those for free as soon as it's out because the Xerces people
will die over it for us... and this is great :)

------- XSL ----------------

FO reached final recommendation. Didn't looked at latest changes but I
hope it solidifies so that people will actually start using it.

I still believe a lot more in CSS than FO for digital publishing on the
client side... but CSS are somewhat limited (no attribute styling in
level2, hopefully will come later with more-or-less XPath capabilities
in their semantics).

Anyway, FOP will implement the spec and we'll proudly use FOP as a PDF
serializer (heard wild plans for RDF support as output format as well).

-------- SVG -----------------

SVG is simply great! We _need_ SVG->raster generation to allow easier
transition to this technology. Pier used a wrapped-up CSIRO serializer
at ApacheCON that works, but I want full support for filters!!!

The FOP project has people working on SVG support (even if this is not
very public at this point) and, to me, makes perfect sense to add JPG
rendering capabilities to FOP and use FOP for both SVG and FO
generation, rather than using a specific package for FO and another for

Still I don't know how fast this would be. If you guys like the idea as
much as I do, please, join the FOP project and help.

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

Wild, to say the least. I'd welcome such a think, even if I don't think
many of us have access to a satellite transponder to play around with it

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]!

---------- RDF/RSS -------------

No particular plans for it. JetSpeed is great at it's job and, as far as
we are concerned, they are just XML documents so we are able to publish
RSS information dynamically out of a database, for example. Nothing
different from any other XML format and do not require specific

---------- DocBook --------------

Same as above. Heard that DocBook 5.0 will target for XML. That is very
nice. Also plan to work with Norman to move all the cocoon documentation
into DocBook, as well as porting a docbook-> stylebook

Will also help Norman with the DocBook->FO XSLT stylesheets since I need
those for my thesis (which, of course, will be written in XML and
formatted using Cocoon: very nice recursion, don't you think? :)

Ok, enough for tonight. Stay tuned for a new episode of "[RT]" :)

taa, da da daa, ta da daaa (startrek NG tune fading away...)

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