cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: XML Query language
Date Wed, 16 Feb 2000 00:11:37 GMT
Darren Scott 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

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

> If there is an argument against it, then it would be from either a
> security standpoint - i.e. a user may be able to access parts of a
> document to which he/she should not be able to, although this could
> easily be avoided by the author. The other argument surely should be
> from a compatibility standpoint - in that because browsers choose to
> interpret the # part themselves, that has become the norm.

yep, I'm not sure how portable something like this would be... any

> I don't know about sitemaps, is there more info on Can
> you give me an indication of the better ways.

Again, look here

> > At the end, more and more people think at XML as a data-storage
> > facility. And XPath as a good way of replacing queries and get a hold on
> > the required data. Also, some want to add Persistent-DOM capabilities to
> > totally eliminate database requirements...

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

> > Well, this is _exactly_ one scary thing about XML: it's too flexible.
> > Many don't see (yet!) the problems that lay ahead.

> I agree. I don't want to appear argumentative (I love a debate), but I
> am unconvinced. Have you considered this issue before? What were your
> conclusions? Have the W3C reconsidered their position on using XPath in
> a URL (I think it was called XQL at the time).

XQL and XPath are not the same thing. XPath is a way to specify
locations of hierarchical content. Using such locations, matching
capabilities and simple functions, this is transformed into a query

Xpath can be seen as the XML-equivalent of regular expressions.

Now: it would be possible to use regular expressions to do database
queries. or even to use URLs with #reg-exps at the end to provide web
content, but, IMO, this follows the "golden hammer" anti-pattern:

 "when you hold a hammer, everything looks like a nail" 

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


C'mon, do you understand how painful is to manage something like this?

URLs are things that never change. In fact a perfect web site doesn't
even specify file extentions so the above would be


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.


View raw message