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 17173 - Inconsistent is-id behavior for updated attributes
Summary: Inconsistent is-id behavior for updated attributes
Status: NEW
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Update Facility (show other bugs)
Version: Recommendation
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Jonathan Robie
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-05-24 21:21 UTC by Josh Spiegel
Modified: 2013-07-15 10:05 UTC (History)
1 user (show)

See Also:


Attachments

Description Josh Spiegel 2012-05-24 21:21:56 UTC
Whenever an XDM attribute is brought into the world, the XQuery and XDM specifications ensure that if its name is xml:id:
  (a) the is-id property is set to true and 
  (b) the attribute value has undergone xml:id processing.

Example 1: XDM Attribute Conversion
http://www.w3.org/TR/xpath-datamodel/#const-infoset-attribute
is-id "If the attribute is named xml:id and its [attribute type] property does not have the value ID, then [xml:id] processing is performed. This will assure that the value does have the type ID and that it is properly normalized"

Example 2: Attribute construction
http://www.w3.org/TR/xquery/#id-attributes (bullet 5)
"If the attribute name is xml:id, then xml:id processing is performed as defined in [XML ID]. This ensures that the attribute has the type xs:ID and that its value is properly normalized. "

It looks like the XQuery Update Facility also tries to maintain this policy. 

Example 3:
http://www.w3.org/TR/xquery-update-10/#id-upd-rename (bullet 2. c.)
"If $newName is xml:id, the is-id property of $target is set to true."

Example 4:
http://www.w3.org/TR/xquery-update-10/#id-upd-set-to-untyped (bullet 2. d.)
"is-id is set to false if the attribute name is not xml:id."

But, I think there might be some holes in the XQUF specification with respect to this.

Problem 1:  It is possible to cause an attribute named xml:id to have is-id set to false. 
----------------------------------------

    copy $doc := document { <e xml:id="bar"/> }
    modify replace value of node $doc/e/@xml:id with "foo"
    return fn:id("foo", $doc)

I think that the result of this query should be <e xml:id="foo"/> but according to the spec the answer should be ().  The replace expression will create a upd:replaceValue primitive which in turn will use upd:removeType on the attribute node.  upd:removeType will set is-id to false, creating an attribute named xml:id with is-id false. 

Problem 2:  It is possible to produce an attribute named xml:id with is-id set to true where the value has not undergone xml:id processing
----------------------------------------

    copy $e := <e a="foo     bar"/> 
    modify rename node $e/@a as xs:QName("xml:id")
    return $e

Possibly the result of this query should be <e xml:id="foo bar"/> but currently I think it would be <e xml:id="foo     bar"/>.  That is, the XQUF does not specify that xml:id processing should be performed on the value.  

And you can also combine problem 1 and problem 2 (an attribute named xml:id with is-id set to false and no xml:id normalization):

    copy $e := <e xml:id="x"/> 
    modify replace value of node $e/@xml:id with "foo    bar"
    return $e