Lists Home |
Date Index |
Elliotte Rusty Harold wrote:
> Nobody's going to confuse Java or SQL with XML. People will confuse
> XQuery with XML.
But people wanting to embed Java or SQL in an XML document will have the
same problems as people wanting to embed XQuery in an XML document.
(Those less-than signs in where clauses are still going to cause
problems.) My guess is that putting XQuery statements into an XML
document is a less than 20% case, and removing the XML-like constructor
syntax will just make life unnecessarily difficult on the remaining
> Languages designed for processing XML documents should either be XML
> themselves (XSLT, Schemas) or totally non-XML (XPath) but in-between
> these two poles lies disaster.
Well, you've certainly got more experience with everyday users than I
do, but I'm less than convinced :)
> I want both at the same time, and see no reason I can't have that.
> :-) For the record, I specifically reject any syntax so complicated
> that I can't write it in BBEdit. i.e. no special tools should be
> necessary to generate an XQuery.
> I'm smart enough to write SQL and
> XSLT by hand. Why does XQuery need to be any more complex than this?
I don't think the current syntax is.
> That rules XQueryX as it exists now, but it could be fixed if that
> were considered desirable by the working group.
I'm less than convinced. Experience with schema languages suggests that
XML-izing things often makes them harder to read. In fact, the only XML
stuff I've seen that's easy to read is: (a) documents a la XHTML, and
(b) XML that looks like object serializations.