[xquery-talk] Re: Attribute node whose parent is a document node

[Michael Kay]

Sorry for the delay in responding.

> 
> Now, consider this :
> 
> let $a :=
>   <root>
>     <foo name1="bar1"/>
>     <bar/>
>     <foo name2="bar2"/>
>   </root>
> 
> return  
>   <result>{$a/(bar|foo/@*)}</result>
> 
> Error on line 9 of file:/C:/saxon8.5/in.txt:
>   XQTY0024: An attribute node (name2) cannot be created after 
> the children of
> the containing element
> Query processing failed: Run-time errors were reported
> 
> [see note below]
> 
> Given the following statement 
> (http://www.w3.org/TR/xquery/#id-content) :
> 
> >together with all the attribute nodes in the content sequence, in
> >implementation-dependent order
> 
> I would have expected :
> 
> <?xml version="1.0" encoding="UTF-8"?>
> <result name1="bar1" name2="bar2"/>
>    <bar/>
> </result>
> 
> 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. By the rules for path expressions, the
sequence returned by $a/(bar|foo/@*) (that is, the content sequence) is in
document order, and it therefore contains an attribute node following an
element node.

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

Regards,

Michael Kay
http://www.saxonica.com/