[xquery-talk] Re: Attribute node whose parent is a document node
pierrick.brihaye at culture.gouv.fr
Thu Aug 18 09:42:38 PDT 2005
Michael Kay <mhk at ...> writes:
> (I'm not actually sure whether your note is saying that the spec isn't
> clear, or that you would like the spec to be different?)
Well... I'm not sure as well :-)
> > >together with all the attribute nodes in the content sequence, in
> > >implementation-dependent order
> > i.e. a node with "*all* the attributes in the content sequence".
> You've quoted from rule 5. But rule 4 says:
> "If the content sequence contains an attribute node following a node that is
> not an attribute node, a type error is raised [err:XQTY0024]."
> Generally, the rules should be taken in order. You don't get to rule 5 if
> rule 4 has already raised an error.
OK. It makes sense. Couldn't this order be expressely recalled in the specs ?
> > It looks like the *original* document order also rules here
> > whereas I think that
> > we have a kind of *new* document here (a content sequence).
> > In other terms, I would have expected a "reprocessing" of the
> > path expression
> > result before creating the content sequence.
> > Maybe I've missed something but it appears to me that the
> > writers of the specs
> > wanted to avoid such reprocessings, the most visible
> > consequence being to me the
> > specific treatment of attributes having the same name.
> Yes. It's an important aim (inherited from XSLT) that processing should be
> pipelinable. You should be able to write a result tree sequentially, rather
> than holding it all in memory. Allowing an attribute in the content sequence
> to come after 10,000 child elements would eliminate that possibility. If you
> want to reorder the sequence, you can do it yourself, explicitly.
I fully understand (and approve) this concern but, isn't it an *implementation*
concern (that may involve a "pipelinable" execution setting) ?
(Re)ordering attributes, making them unique for a given name, at risk of getting
an XQTY0024 brings IMHO us far from the XML spirit where we can have as many
unordered attributes as required.
So... the specs may indeed need a small rewriting including :
- explicitely prioritized rules
- design considerations (especially regarding attributes uniqueness)
- non-working examples
- eventually, the definition of an "unpipelined" mode (that no processor will
ever implement, for sure ;-)
More information about the talk