This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 5334 - [UPD] Inserting attributes
Summary: [UPD] Inserting attributes
Status: CLOSED WONTFIX
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Update Facility (show other bugs)
Version: Last Call drafts
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Andrew Eisenberg
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-01-01 22:15 UTC by Michael Kay
Modified: 2008-01-26 22:59 UTC (History)
0 users

See Also:


Attachments

Description Michael Kay 2008-01-01 22:15:06 UTC
The rules on insertion of attributes seem highly arbitrary.

You are allowed to say

insert node @a after $x/*[12]

and it happily adds a copy of @a to $x, ignoring the requested position.

You can also say

insert nodes (@a, <e/>) after $x/*[12]

and it happily inserts @a as an attribute of $x, and adds <e/> as its 13th child element.

But you can't say

insert nodes (<e/>, @a) after $x/*[12]

because the source expression isn't allowed to have an attribute appearing after a non-attribute.

This seems very inconsistent. I would suggest either relaxing the rules by eliminating error XUTY0004, or making the rules stricter by disallowing all use of positional qualifiers (after, before, as first, as last) when the source expression contains an attribute.
Comment 1 Don Chamberlin 2008-01-15 01:09:54 UTC
Eliminating XUTY0004 seems reasonable. It was defined by analogy with XQTY0024, but it could be argued that the analogy is weak because XQTY0024 applies only to element constructors.
Comment 2 zhen hua liu 2008-01-15 19:29:32 UTC
I'd like to retain what the current xquery update spec states, that is, XUTY0004 to be raised for the following reasons:
(1) It is consistent with the xquery 1.0 for element constructor for raising 
XQTY0024 error.
(2) The original reason, I suspected, that XQTY0024 error is raised for element
constructor, is for streaming implementation. I think similar arguments held for
insert node.
(3) Some implementations may rewrite (transform) some 'insert expression' into
element constructor. In such case, it is appreciated they share the same rules.
Comment 3 Jonathan Robie 2008-01-22 19:56:39 UTC
In XQuery 1.0, this raises an error:

let $x := 
 ( attribute a { "a" },
   element b { "b" },
   attribute c { "c" } )
return 
<foo>
 { $x }
</foo>

That leads me to expect the following to be an error:

let $x := 
 ( attribute a { "a" },
   element b { "b" },
   attribute c { "c" } )
let $f := <foo></foo>
return insert nodes $x into $f
Comment 4 Michael Kay 2008-01-22 20:47:11 UTC
Concerning comment #3: yes, for "insert into" that would be a reasonable expectation. What makes it unreasonable is that we allow "insert after" to insert a new attribute "after" an existing child element. If there's an existing child <c/> and we can insert (@a, <e/>) after <c/>, then clearly this involves some rearrangement of the sequence (@a, <e/>); and if this sequence can be rearranged, then so can (<e/>, @a).
Comment 5 Don Chamberlin 2008-01-26 22:04:41 UTC
Michael,
On 22 Jan 2008, the Query Working Group decided not to make any change to the Update specification based on this bug report. The reason for this decision is to preserve consistency between insert expressions and element constructors in XQuery 1.0. If you are satisfied with this resolution, please change the status of this bug to Closed.
--Don Chamberlin (for the Query Working Group)