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

Pierrick Brihaye pierrick.brihaye at culture.gouv.fr
Fri Aug 12 10:30:17 PDT 2005


Hi,

Michael Kay <mhk at ...> writes:

>

Reviving this thread after some (long) vacations. A good suprise was waiting for
me : Saxon 8.5 ;-)

Let's reorder the previous discussions.

> There are a few cases like this where Saxon is currently issuing an XSLT
> error code rather than an XQuery error code. It tends to happen in cases
> where the underlying run-time code has no knowledge of which host language
> was used to generate the code. I fix these as I come across them. But the
> error message is basically correct, as I assume you realise.

I do. The new Saxon has nice improvements in this domain. Thanks !

> Of course. But it's more reliable than inferring the spec from the behaviour
> of implementations - especially in corner cases!

inferring = deducting (specs -> implementation) and inducting (implementation ->
specs). So, yes, I admin I'm inferring :-)

>and it has two attributes of the same name

I find this statement of the specs a little bit rude (XML does allow attributes
with the same name). What is the motivation behind it ? Duplicates hunt ?
Something else I will discuss below ?

Let's come back to :

> > > attributes consist of all the attributes specified in the 
> > start tag as described in 3.7.1.1 Attributes, together with 
> > all the attribute nodes in the content sequence, in 
> > implementation-dependent order.
> > 
> > How should I interpret "all the attribute nodes in the 
> > content sequence"
> 
> I can't quite see where your difficulty is in interpreting this phrase.

> > But... how does this cope with the definition given at 
> > http://www.w3.org/TR/xpath20/#dt-document-order ?
> 
> I don't understand your difficulty. There are three attributes, and they
> have a well-defined document order. What are you trying to "cope with"?

Let's try to explain what I find to be a contradiction between the specs :

Consider :

let $a :=
  <root>
    <foo name1="bar1"/>
    <bar/>
    <foo name2="bar2"/>
  </root>

for $b in $a/(bar|foo/@*)
return  
  <result>{$b}</result>

I get :

<?xml version="1.0" encoding="UTF-8"?>
<result name1="bar1"/>
<result>
   <bar/>
</result>
<result name2="bar2"/>

replacing :
for $b in $a/(bar|foo/@*)
by : 
for $b in $a/(foo/@*|bar)

returns the same result because *document order* rules. Fine.

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

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.

What do you think ?

<saxon8.5_note>

With :

let $a :=
  <root>
    <foo name2="bar2"/>
    <foo name2="bar2"/>
  </root>

return  
  <result>{$a/foo/@name2}</result>

I get :

Error on line 8 of file:/C:/saxon8.5/in.txt:
  XQDY0025: Cannot create an element having two attributes with the same name: @
name2
Query processing failed: Run-time errors were reported

Notice that we have "@name2". Previously, we had  (name2)

</saxon8.5_note>

Cheers,

p.b.






More information about the talk mailing list