Discussion:
Attribute node whose parent is a document node
(too old to reply)
Pierrick Brihaye
2005-07-07 19:28:02 UTC
Permalink
Hi,

Given the following query :

let $a :=
<root>
<county name="Devon">
<district name="East Devon">
<town name="Axminster" pct="East Devon">
<town name="Abbey Gate"/>
</town>
<town name="Aylesbeare" pct="East Devon"/>
</district>
</county>
</root>

let $b :=
for $town in $a/county/district/town
where ($town/../@name eq "East Devon" or $town/../@name eq "Exeter")
order by $town/@name ascending
return $town/@name

let $c :=
for $town in $a/county/district[@name = "East Devon" or @name =
"Exeter"]/town
order by $town/@name ascending
return $town/@name

return ($b,<blah/>,$c)

... Saxon returns :

XTDE0410: Cannot create an attribute node whose parent is a document node

Given this slight modification :

let $a :=
<root>
<county name="Devon">
<district name="East Devon">
<town name="Axminster" pct="East Devon">
<town name="Abbey Gate"/>
</town>
<town name="Aylesbeare" pct="East Devon"/>
</district>
</county>
</root>

let $b :=
for $town in $a/county/district/town
where ($town/../@name eq "East Devon" or $town/../@name eq "Exeter")
order by $town/@name ascending
return $town

let $c :=
for $town in $a/county/district[@name = "East Devon" or @name =
"Exeter"]/town
order by $town/@name ascending
return $town

return ($b,<blah/>,$c)

... Saxon returns :

<?xml version="1.0" encoding="UTF-8"?>
<town pct="East Devon" name="Axminster">
<town name="Abbey Gate"/>
</town>
<town pct="East Devon" name="Aylesbeare"/>
<blah/>
<town pct="East Devon" name="Axminster">
<town name="Abbey Gate"/>
</town>
<town pct="East Devon" name="Aylesbeare"/>

So what's happening ?

Note that my primary purpose was to test the functional equivalence
between a "where" statement and a predicate filtering.

Cheers,

p.b.
Wolfgang Hoschek
2005-07-07 19:40:31 UTC
Permalink
This is most likely because the W3C draft XQuery serialization spec
disallows top-level attributes (and namespace nodes) on
serialization. (This can be avoided with the Saxon -wrap option).

Hth, Wolfgang.
Post by Pierrick Brihaye
Hi,
let $a :=
<root>
<county name="Devon">
<district name="East Devon">
<town name="Axminster" pct="East Devon">
<town name="Abbey Gate"/>
</town>
<town name="Aylesbeare" pct="East Devon"/>
</district>
</county>
</root>
let $b :=
for $town in $a/county/district/town
let $c :=
"Exeter"]/town
return ($b,<blah/>,$c)
XTDE0410: Cannot create an attribute node whose parent is a
document node
let $a :=
<root>
<county name="Devon">
<district name="East Devon">
<town name="Axminster" pct="East Devon">
<town name="Abbey Gate"/>
</town>
<town name="Aylesbeare" pct="East Devon"/>
</district>
</county>
</root>
let $b :=
for $town in $a/county/district/town
return $town
let $c :=
"Exeter"]/town
return $town
return ($b,<blah/>,$c)
<?xml version="1.0" encoding="UTF-8"?>
<town pct="East Devon" name="Axminster">
<town name="Abbey Gate"/>
</town>
<town pct="East Devon" name="Aylesbeare"/>
<blah/>
<town pct="East Devon" name="Axminster">
<town name="Abbey Gate"/>
</town>
<town pct="East Devon" name="Aylesbeare"/>
So what's happening ?
Note that my primary purpose was to test the functional equivalence
between a "where" statement and a predicate filtering.
Cheers,
p.b.
_______________________________________________
http://xquery.com/mailman/listinfo/talk
Pierrick Brihaye
2005-07-07 19:59:51 UTC
Permalink
Hi,
Post by Wolfgang Hoschek
This is most likely because the W3C draft XQuery serialization spec
disallows top-level attributes (and namespace nodes) on serialization.
(This can be avoided with the Saxon -wrap option).
Am I in at the top level ? Iwanted to write :

let $a :=
<county name="Devon">
<district name="East Devon">
<town name="Axminster" pct="East Devon">
<town name="Abbey Gate"/>
</town>
<town name="Aylesbeare" pct="East Devon"/>
</district>
</county>

rather than :

let $a :=
<root>
<county name="Devon">
<district name="East Devon">
<town name="Axminster" pct="East Devon">
<town name="Abbey Gate"/>
</town>
<town name="Aylesbeare" pct="East Devon"/>
</district>
</county>
</root>

... which included a "pseudo-root" element.

Can't figure out what happens on this one :-)

Cheers,

p.b.
Wolfgang Hoschek
2005-07-07 20:14:27 UTC
Permalink
"top-level" node = parentless node
See item 7 at http://www.w3.org/TR/xslt-xquery-serialization/#serdm

Wolfgang.
Post by Pierrick Brihaye
Hi,
Post by Wolfgang Hoschek
This is most likely because the W3C draft XQuery serialization
spec disallows top-level attributes (and namespace nodes) on
serialization. (This can be avoided with the Saxon -wrap option).
let $a :=
<county name="Devon">
<district name="East Devon">
<town name="Axminster" pct="East Devon">
<town name="Abbey Gate"/>
</town>
<town name="Aylesbeare" pct="East Devon"/>
</district>
</county>
let $a :=
<root>
<county name="Devon">
<district name="East Devon">
<town name="Axminster" pct="East Devon">
<town name="Abbey Gate"/>
</town>
<town name="Aylesbeare" pct="East Devon"/>
</district>
</county>
</root>
... which included a "pseudo-root" element.
Can't figure out what happens on this one :-)
Cheers,
p.b.
_______________________________________________
http://xquery.com/mailman/listinfo/talk
Pierrick Brihaye
2005-07-07 20:50:04 UTC
Permalink
Hi,
Post by Wolfgang Hoschek
"top-level" node = parentless node
See item 7 at http://www.w3.org/TR/xslt-xquery-serialization/#serdm
Sorry, Im really stuck here. *who* has no parent ? The node in the for
statement ($town) ?

BTW, having tried this :

let $a :=
<root>
<county name="Devon">
<district name="East Devon">
<town name="Axminster" pct="East Devon">
<town name="Abbey Gate"/>
</town>
<town name="Aylesbeare" pct="East Devon"/>
</district>
</county>
</root>

let $b :=
for $town in $a/county/district/town
where ($town/../@name eq "East Devon")
return $town

let $c :=
for $town in $a/county/district[@name = "East Devon"]/town
return $town

return
(<attribute>{$a/county/district/town/@name}</attribute>,$b,<blah/>,$c)

... I get :

<?xml version="1.0" encoding="UTF-8"?>
<attribute name="Aylesbeare"/>
<town pct="East Devon" name="Axminster">
<town name="Abbey Gate"/>
</town>
<town pct="East Devon" name="Aylesbeare"/>
<blah/>
<town pct="East Devon" name="Axminster">
<town name="Abbey Gate"/>
</town>
<town pct="East Devon" name="Aylesbeare"/>

Where does <attribute name="Aylesbeare"/> come from ?

Cheers,

p.b.
Wolfgang Hoschek
2005-07-07 21:09:54 UTC
Permalink
Post by Pierrick Brihaye
Sorry, Im really stuck here. *who* has no parent ? The node in the
for statement ($town) ?
The issue can be simplified to these two cases:

let $a := <county name="Devon"/>
return $a/@name (: W3C spec says top-level attributes can't be
serialized :)


let $a := <county name="Devon"/>
return $a (: fine :)


(Both cases will work fine with the -wrap option).
Wolfgang.
Pierrick Brihaye
2005-07-07 21:17:49 UTC
Permalink
Hi,
Post by Wolfgang Hoschek
let $a := <county name="Devon"/>
serialized :)
OK. I can understand that (perhaps more on this tomorrow ;-).

My problem is that the error message was returned by :

root/county/district/town
or
root/county/district/town/town

At least 3 parents, uh ?

I may be missing something obvious, but what ?

Cheers,

p.b.
Wolfgang Hoschek
2005-07-07 21:27:19 UTC
Permalink
Post by Pierrick Brihaye
Hi,
Post by Wolfgang Hoschek
let $a := <county name="Devon"/>
serialized :)
OK. I can understand that (perhaps more on this tomorrow ;-).
root/county/district/town
or
root/county/district/town/town
At least 3 parents, uh ?
I may be missing something obvious, but what ?
Cheers,
p.b.
Perhaps you are confusing which tests worked and which didn't. Could
you retry?
Regards,
Wolfgang.
Pierrick Brihaye
2005-07-07 21:30:51 UTC
Permalink
Hi again,
Post by Pierrick Brihaye
root/county/district/town
or
root/county/district/town/town
At least 3 parents, uh ?
I may be missing something obvious, but what ?
OK. I've got it. An easy demonstration from this query :

let $a := <county name="Devon"/>
let $b := "Devon"

return ($a/@name, $b)

With the -wrap paramter in Saxon, everything becomes clear :

<result:sequence xmlns:result="http://saxon.sf.net/xquery-results"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<result:attribute name="Devon"/>
<result:atomic-value xsi:type="xs:string">Devon</result:atomic-value>
</result:sequence>

In french : "il ne faut pas mélanger les torchons et les serviettes" :-)

Any hint on my <attribute>{$a/county/district/town/@name}</attribute>
processing ?

Thank you very much. Good night.

p.b.
Howard Katz
2005-07-07 23:08:18 UTC
Permalink
-----Original Message-----
Sent: Thursday, July 07, 2005 2:31 PM
Subject: [xquery-talk] Re: Attribute node whose parent is a
document node
[ snip ... ]
processing ?
[ from an earlier email ... ]
Where does <attribute name="Aylesbeare"/> come from ?
That's interesting. To recap (and simplify) the piece of code that's
producing the result you're getting:

let $a :=
<root>
<county name="Devon">
<district name="East Devon">
<town name="Axminster" pct="East Devon">
<town name="Abbey Gate"/>
</town>
<town name="Aylesbeare" pct="East Devon"/>
</district>
</county>
</root>

return
<attribute>{ $a/county/district/town/@name }</attribute>

Your code is trying to return the two @name attributes that are reachable
via the given path. These are then getting "hoisted" as attributes into the
newly constructed <attribute> element containing them.

The latest version of the spec says that having duplicate attributes (ie
attributes of the same name, something not permitted in xml) in a direct
element constructor should raise a static error. Saxon leniently resolves
the issue by simply picking the second of the two ("Aylesbeare"), while
Galax even more accomodatingly accepts both:

<attribute name="Axminster" name="Aylesbeare"/>

Mark Logic, tho operating under an older spec, says "XML Parsing Error:
duplicate attribute", which seems to be in accord with the latest version of
the wd.

Anyone disagree with how I'm reading the spec?

Howard
Pierrick Brihaye
2005-07-08 07:19:58 UTC
Permalink
Hi,
Post by Howard Katz
[ from an earlier email ... ]
Post by Pierrick Brihaye
Where does <attribute name="Aylesbeare"/> come from ?
That's interesting.
Isn't it ? :-)
Post by Howard Katz
Your code is trying to return the two <at> name attributes that are reachable
via the given path.
Correct.
Post by Howard Katz
These are then getting "hoisted" as attributes into the
newly constructed <attribute> element containing them.
Would the term "attached" be accurate here ? See below...
Post by Howard Katz
The latest version of the spec says that having duplicate attributes (ie
attributes of the same name, something not permitted in xml) in a direct
element constructor should raise a static error. Saxon leniently resolves
the issue by simply picking the second of the two ("Aylesbeare"), while
<attribute name="Axminster" name="Aylesbeare"/>
So does eXist.
Post by Howard Katz
duplicate attribute", which seems to be in accord with the latest version of
the wd.
We may report an error. We have one for parentless attribute nodes as seen
yesterday. It could make sense to have one for attribute nodes whose parent is
not their original one (may we speak about "forced adoption" ?).

I'm also really surprised that an element's *content* may generate an attribute
for this element. It should IMHO generate an error *except* if a construct
similar to <xsl:attribute> is used.

What's your mind ?

<sience-fiction>
We could have a function, say "attach()", that would allow to attach a node to
another thus allowing "forced adoption". Ideally, this function could work on
different axes (I will try to provide some pseudo-examples for this) but maybe a
function dedicated to attributes would be sufficient :
<attribute>{attachAttributes($a/county/district/town/@name[1 to X])}</attribute>
Of course, this function would also be applicable to parentless attributes ;-)
</sience-fiction>

BTW, couldn't Saxon generate a nicer error message ? Something like :
Cannot create an attribute node whose parent is a document node (@name =
'Axminster')

Cheers,

p.b.
Howard Katz
2005-07-08 12:40:25 UTC
Permalink
[ snip ... ]
Post by Pierrick Brihaye
Post by Howard Katz
Mark Logic, tho operating under an older spec, says "XML
duplicate attribute", which seems to be in accord with the latest
version of the wd.
We may report an error. We have one for parentless attribute
nodes as seen yesterday. It could make sense to have one for
attribute nodes whose parent is not their original one (may
we speak about "forced adoption" ?).
I'm also really surprised that an element's *content* may
generate an attribute for this element. It should IMHO
generate an error *except* if a construct similar to
<xsl:attribute> is used.
What's your mind ?
I do view it as similar to <xsl:attribute>. I don't see it as an error, any
more than saying that what's inside <e> { doc( ... )//sub-e } </e> is an
error or a non-intuitive way of generating sub-elements inside content. It's
just a mechanism for moving existing attributes from one place to another,
which make take a bit of getting used to the first time it's encountered.

Howard
Michael Kay
2005-07-09 08:36:40 UTC
Permalink
Post by Pierrick Brihaye
Cannot create an attribute node whose parent is a document
'Axminster')
Thanks for the suggestion.

Michael Kay
http://www.saxonica.com/
Pierrick Brihaye
2005-07-09 08:53:05 UTC
Permalink
Hi,

Coming back to this. Thank you for your exaplanations, which make the
things clearer to me.
Post by Pierrick Brihaye
I'm also really surprised that an element's *content* may generate an attribute
for this element. It should IMHO generate an error *except* if a construct
similar to <xsl:attribute> is used.
When I use :

let $a :=
<root>
<county name="Devon">
<district name="East Devon">
<town name="Axminster" pct="East Devon">
<town name="Abbey Gate"/>
</town>
<town name="Aylesbeare" pct="East Devon"/>
</district>
</county>
</root>

return
<attribute>{ $a/county/district/town/@name }</attribute>

My first understanding was that we have an <xsl:value-of> behaviour. It
appears that we are a behaviour which is closer to <xsl:copy-of>. I can
figure this out this way :

let $a :=
<root>
<county name="Devon">
<district name="East Devon">
<town name="Axminster" pct="East Devon">
<town name="Abbey Gate"/>
</town>
<town name="Aylesbeare" pct="East Devon"/>
</district>
</county>
</root>

return
<attribute>some text{ $a/county/district/town/@name }</attribute>

... which returns a clean explanation :

XTDE0420: Attribute nodes must be created before the children of an
element node

[BTW : we could have a message giving the (attribute) node's name]

Cheers,

p.b.
Michael Kay
2005-07-09 10:32:33 UTC
Permalink
Post by Pierrick Brihaye
My first understanding was that we have an <xsl:value-of>
behaviour. It
appears that we are a behaviour which is closer to
<xsl:copy-of>. I can
You can also figure it out by reading the spec.

Yes, the content constructor for XQuery element construction behaves very
similarly to xsl:copy-of. If you want the values atomized (xsl:value-of) you
can achieve this using functions such as string() or data().

Michael Kay
http://www.saxonica.com/
Pierrick Brihaye
2005-07-09 19:02:18 UTC
Permalink
Post by Michael Kay
You can also figure it out by reading the spec.
Yes :-) However, it's a difficult exercise. Please consider this (crazy)
example :

let $a :=
<root>
<foo name="bar"/>
<name name="foo">bar</name>
<foo name="bar"/>
</root>

return
<result>{($a//@name|$a//name)}</result>

As discussed earlier, I get an XTDE0420 error from Saxon as mentionned
Post by Michael Kay
It is a non-recoverable dynamic error if the result sequence used to construct the content of a document node contains a namespace node or attribute node.
If the content sequence contains an attribute node following a node that is not an attribute node, a type error is raised [err:XQTY0024].
Aren't we in this case ? Am I faced to an XSLT or an XQuery error ?
Post by Michael Kay
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"
? Aren't there 3 attributes in my content sequence as demonstrated by :

let $a :=
<root>
<foo name="bar"/>
<name name="foo">bar</name>
<foo name="bar"/>
</root>

return
for $b in $a//@name
return <attribute>{$b}</attribute>

which obviously returns :

<attribute name="bar"/>
<attribute name="foo"/>
<attribute name="bar"/>

But... how does this cope with the definition given at
http://www.w3.org/TR/xpath20/#dt-document-order ?
Post by Michael Kay
If two or more of these attributes have the same node-name, a dynamic error is raised [err:XQDY0025]. Note that the parent property of each of these attribute nodes has been set to the newly constructed element node.
... and thus get an XQDY0025 error ?

PS or course explicitely ordering my sequence :

let $a :=
<root>
<foo name="bar"/>
<name name="foo">bar</name>
<foo name="bar"/>
</root>

<result>{($a//@name,$a//name)}</result>)

...returns no error:

<result name="bar">
<name name="foo">bar</name>
</result>

... although I may have wanted 2 attributes in my <result> element (this
should be fixed in the next version, shouldn't it ?).

Cheers,

p.b.
Michael Kay
2005-07-10 09:47:47 UTC
Permalink
Post by Pierrick Brihaye
Yes :-) However, it's a difficult exercise.
Of course. But it's more reliable than inferring the spec from the behaviour
of implementations - especially in corner cases!

Please consider
Post by Pierrick Brihaye
this (crazy)
let $a :=
<root>
<foo name="bar"/>
<name name="foo">bar</name>
<foo name="bar"/>
</root>
return
As discussed earlier, I get an XTDE0420 error from Saxon as
mentionned
Post by Michael Kay
It is a non-recoverable dynamic error if the result
sequence used to construct the content of a document node
contains a namespace node or attribute node.
Actually, the error message is

XTDE0420: Attribute nodes must be created before the children of an
element node

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.

Error codes were only introduced into Saxon very recently, and at present
they aren't always correct. This is generally because the error (eg. an
undeclared namespace prefix) is detected at a level in the code where one
test is detecting several different error conditions defined separately in
the spec. You can expect this situation to improve gradually over time as
the test suite expands. Please report any discrepancies that you find.
Post by Pierrick Brihaye
Post by Michael Kay
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.
Post by Pierrick Brihaye
? Aren't there 3 attributes in my content sequence
Yes, there are.
Post by Pierrick Brihaye
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"?
Post by Pierrick Brihaye
Post by Michael Kay
If two or more of these attributes have the same node-name,
a dynamic error is raised [err:XQDY0025]. Note that the
parent property of each of these attribute nodes has been set
to the newly constructed element node.
... and thus get an XQDY0025 error ?
Yes, an implementation could legitimately return this error instead of
XQTY0024. Your content sequence breaks both rules: it has an attribute after
an element, and it has two attributes of the same name. In these cases it's
clear that the system can report either error (or both, if it wishes).
Post by Pierrick Brihaye
let $a :=
<root>
<foo name="bar"/>
<name name="foo">bar</name>
<foo name="bar"/>
</root>
<result name="bar">
<name name="foo">bar</name>
</result>
As previously mentioned, you should get an error XQDY0025 in this case.

Michael Kay
http://www.saxonica.com/
Pierrick Brihaye
2005-08-12 09:30:17 UTC
Permalink
Hi,

Michael Kay <***@...> writes:
Reviving this thread after some (long) vacations. A good suprise was waiting for
me : Saxon 8.5 ;-)

Let's reorder the previous discussions.
Post by Michael Kay
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 !
Post by Michael Kay
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 :-)
Post by Michael Kay
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 ?
Post by Michael Kay
Post by Michael Kay
Post by Michael Kay
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.
Post by Michael Kay
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]
Post by Michael Kay
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.
Michael Kay
2005-08-17 18:19:29 UTC
Permalink
Sorry for the delay in responding.
Post by Pierrick Brihaye
let $a :=
<root>
<foo name1="bar1"/>
<bar/>
<foo name2="bar2"/>
</root>
return
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
Post by Michael Kay
together with all the attribute nodes in the content sequence, in
implementation-dependent order
<?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.
Post by Pierrick Brihaye
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/
Pierrick Brihaye
2005-08-18 08:42:38 UTC
Permalink
Hi,
Post by Michael Kay
(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 :-)
Post by Michael Kay
Post by Pierrick Brihaye
Post by Michael Kay
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".
"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 ?
Post by Michael Kay
Post by Pierrick Brihaye
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 ;-)


Cheers,

p.b.

Michael Kay
2005-07-09 08:01:31 UTC
Permalink
Post by Howard Katz
That's interesting. To recap (and simplify) the piece of code that's
let $a :=
<root>
<county name="Devon">
<district name="East Devon">
<town name="Axminster" pct="East Devon">
<town name="Abbey Gate"/>
</town>
<town name="Aylesbeare" pct="East Devon"/>
</district>
</county>
</root>
return
are reachable via the given path...
The latest version of the spec says that having duplicate
attributes (ie
attributes of the same name, something not permitted in xml)
in a direct
element constructor should raise a static error.
This isn't a static error - there aren't two name attributes on the same
element constructor in the source query. It's a dynamic error, XQDY0025, as
described in section 3.7.1.3, clause 5d.
Post by Howard Katz
Saxon leniently resolves
the issue by simply picking the second of the two
("Aylesbeare")
Saxon appears to be incorrectly implementing the XSLT semantics here rather
than the XQuery semantics. XSLT always chooses the last of several
attributes with the same name. There seems to be a switch in the code to
enforce the stricter XQuery rules in the path that creates new attributes,
but not in the path that copies existing attributes.

Michael Kay
http://www.saxonica.com/
Michael Kay
2005-07-09 08:22:36 UTC
Permalink
Post by Michael Kay
Saxon appears to be incorrectly implementing the XSLT
semantics here rather
than the XQuery semantics.
It turns out this bug is already fixed in my current development build.

Michael Kay
http://www.saxonica.com/
Michael Kay
2005-07-08 23:45:25 UTC
Permalink
You're missing that the serializer effectively wraps a document{}
constructor around your query to make the result into a document.
document{@x} gives you an error because you can't add an attribute node to a
document node.

Michael Kay
http://www.saxonica.com/
-----Original Message-----
Sent: 07 July 2005 22:18
Subject: [xquery-talk] Re: Attribute node whose parent is a
document node
Hi,
Post by Wolfgang Hoschek
let $a := <county name="Devon"/>
serialized :)
OK. I can understand that (perhaps more on this tomorrow ;-).
root/county/district/town
or
root/county/district/town/town
At least 3 parents, uh ?
I may be missing something obvious, but what ?
Cheers,
p.b.
_______________________________________________
http://xquery.com/mailman/listinfo/talk
Michael Kay
2005-07-07 19:58:16 UTC
Permalink
If you look at the serializer spec, you'll see that you can't serialize a
sequence that contains parentless attribute nodes. The default invocation of
Saxon from the command line requests serialization, which is why this is
failing.

Michael Kay
http://www.saxonica.com/
-----Original Message-----
Sent: 07 July 2005 20:28
Subject: [xquery-talk] Attribute node whose parent is a document node
Hi,
let $a :=
<root>
<county name="Devon">
<district name="East Devon">
<town name="Axminster" pct="East Devon">
<town name="Abbey Gate"/>
</town>
<town name="Aylesbeare" pct="East Devon"/>
</district>
</county>
</root>
let $b :=
for $town in $a/county/district/town
let $c :=
"Exeter"]/town
return ($b,<blah/>,$c)
XTDE0410: Cannot create an attribute node whose parent is a
document node
let $a :=
<root>
<county name="Devon">
<district name="East Devon">
<town name="Axminster" pct="East Devon">
<town name="Abbey Gate"/>
</town>
<town name="Aylesbeare" pct="East Devon"/>
</district>
</county>
</root>
let $b :=
for $town in $a/county/district/town
return $town
let $c :=
"Exeter"]/town
return $town
return ($b,<blah/>,$c)
<?xml version="1.0" encoding="UTF-8"?>
<town pct="East Devon" name="Axminster">
<town name="Abbey Gate"/>
</town>
<town pct="East Devon" name="Aylesbeare"/>
<blah/>
<town pct="East Devon" name="Axminster">
<town name="Abbey Gate"/>
</town>
<town pct="East Devon" name="Aylesbeare"/>
So what's happening ?
Note that my primary purpose was to test the functional equivalence
between a "where" statement and a predicate filtering.
Cheers,
p.b.
_______________________________________________
http://xquery.com/mailman/listinfo/talk
Continue reading on narkive:
Loading...