Thomas B. Passin wrote:
> Oh, no, I don't see this at all. I see it in a very
> different way. XQuery is built on a model that includes
> a graph-like info set, a system to navigate around the
> graph, a system to specify and evaluate expressions of a type
> not included in XPath/XSLT, a type system, and a query algebra.
> Only the navigation part is like XPath (it virtually IS XPath).
> And this is as it should be - if you need a tree or "forest"
> navigational system, use XPath (extended if need be).
Well said.
> Me, I like a lot of what I see in the draft XQuery documents.
> I'm really puzzled, though, by what seems to be invalid XML
> illustrated in several places. For example, in the XQuery langugage draft:
>
> ---------------------------------------------------------
> (Q8) Generate an element with a computed name, containing nested
> elements named <description> and <price>.
>
> <$tagname>
> <description> $d </description> ,
> <price> $p </price>
> </$tagname>
This is an element constructor, not an XML literal. It does not need to be valid XML, even though it looks kind of like an XML element.
However, I think it might be easier for people if we *do* make our element constructors virtually identical to normal XML. There would have to be a way to include dynamic parts of a query, which probably requires a syntax not 100% compatible with XML.
> <'FOR' 'LET' = "WHERE"/>
>
>
> I don't understand how expressions like these are supposed
> to appear in a valid XML document. There's nothing I noticed
> about escaping such expressions.
I agree - escaping expressions is probably the most promising way to allow a clean integration of XML syntax with XQuery syntax for element construction.
Jonathan