cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Darren Scott <>
Subject Re: XML Query language
Date Wed, 16 Feb 2000 11:31:49 GMT

Stefano Mazzocchi wrote:
> >
> > I sorta agree in principle, but then that is exactly what Cocoon does,
> > particularly when using the media type negotiation.
> Wrong. Cocoon is using HTTP headers not something inside the URL, big
> difference.

Yes you're right. I didn't make my point clearly. I was responding to
your statement that implied that a single URL should not produce a
different resource on different occasions. Is this what you meant? Also,
Cocoon is pretty unique in that it generates a different result based on
HTTP headers. That's it's power (partly) isn't it? But you'll never
escape from including information in a URL that triggers dynamic
processing on the server side (unless you don't count query strings as
part of a URL - but that's technical pedantics).

> > Also, I can't find
> > the actual RFC (damn it) but I remember reading that the # part of a URL
> > is left open to interpretation by the server, but that it should
> > generally be for locating specific parts (or nodes) of the resource,
> > which is what I propose it be used as.
> Hmmmm, you're talking about XPointer, then?

Well, I was referring to an RFC regarding URL's, not any sort of XML
recomendation, but now you mention it, I think I am talking about
XPointer rather than XPath. I can't find out whether work on XPointer
stopped or whether it developed into XPath.


Crikey, you're talking about developing Cocoon into more of an
Application server than a publishing framework here. 

Most of the attraction to Cocoon is that it is based on XML standards,
so a developer can retain portability without becoming tied to a
particular content delivery platform. There was at least one server-side
XSL processor available before Cocoon came about (docproc? docman?) and
I think another has recently appeared. Cocoon is already pretty portable
itself because it's servlet based, but surely you want to avoid
prohibiting developers from moving away from Cocoon. 

XSP is great, it has a real opportunity to bring all the incompatible
processing systems like JSP, GSP, ASP etc under one umbrella - with many

I'm not saying that Cocoon shouldn't develop into something more, just
that I (I don't know if I speak for anyone else - I know at least one
other person who I speak for!) would not like to use very Cocoon
specific mechanisms for acheiving what I want to do - just like I don't
go casting my HttpServletRequest's into JServConnection's.

> > I think it is becoming a given that XML data storage engines like
> > Excelon will enventually replace RDBMS' - XPath was designed to cope
> > with this very fundmental shift from an orientation towards applications
> > to an orientation towards documents.
> Hmmm, some might no agree with that. I'm mostly on that side: how would
> you do transactions? is XPath orthogonal to ACID properties?
> I don't have a clear opinion on that but I see many dangers in believing
> that since XPath can give you data from a file, then this is equivalent
> to an DBMS.
> This might be a very dangerous approach.

Hmm, I agree that this whole area is fraught with danger. But let's not
forget my original proposal ... a URL identifies an Internet resource,
which is part of a directory, which is part of a filesystem...etc. Why
not also part of a document?

> XPointer is the XML equivalence of HTML anchors, just provide finer
> granularity. It's a totally different thing to add an XPath at the end
> of a URL...
>  http://localhost/index.xml#news[@title=starts-with('computer')]
> C'mon, do you understand how painful is to manage something like this?

That's ridiculus, of course. XPointer is what I was talking about - I
had assumed that XPath was XPointer renamed,as the w3c have gone
completely quiet on XPointer.

I still beleive that, in priciple, having Cocoon process XPointer in a
URL would be a good thing to have - but the more I think of it, the more
problems I think it would cause with existing browsers (an anchor isn't
considered as part of a URL, so the document is never reloaded if the
anchor isn't found. Probably a design flaw (damn, wheres that RFC), but
most of us spend our entire lives working around browser design flaws).

> and the sitemap will know to apply the right transformation to come up
> with the required news from whatever xml-ized source, or, if you want,
> from your own SQLProducer. But from a content-writer point of view, this
> should not be important as long as the wanted output comes out.
> The whole Cocoon deal is about separation of contexts.
> The nasty thing is that context overlaps hide themselves all over the
> place. Even in URI spaces.

Do you see why I would want to avoid sitemaps? Can you think of an
implementation independant (potentially at least) way of solving my
original problem. That is, to have a single XML source with more than
one resource, and one XSL document to render either? 

This can't be an unusual request. Not wanting to teach you to suck eggs
(a British phrase meaning to tell you what you already know), the Cocoon
deal is also about management. I want to avoid maintaining multiple
documents containing the same content in different languages - that's a
management issue, because I don't want to have to edit each document
every time there is a change in the content - just like I don't want to
edit every page on a site if there is a stylistic change. 

Can you see that there is not only a style/content seperation issue
here, there is a content/content amalgamation issue here, too.

Sorry to go on. You've conviced me of the problems with my inital
suggestion, but I still have the same problem. <sound-bite>There must be
some other way...</sound-bite>

Darren Scott
Technical Director

View raw message