W3C home > Mailing lists > Public > public-qt-comments@w3.org > May 2012

[Bug 17173] New: Inconsistent is-id behavior for updated attributes

From: <bugzilla@jessica.w3.org>
Date: Thu, 24 May 2012 21:21:57 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-17173-523@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17173

           Summary: Inconsistent is-id behavior for updated attributes
           Product: XPath / XQuery / XSLT
           Version: Recommendation
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Update Facility
        AssignedTo: jonathan.robie@gmail.com
        ReportedBy: josh.spiegel@oracle.com
         QAContact: public-qt-comments@w3.org
             Group: XSLXQuery_WG


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

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Thursday, 24 May 2012 21:22:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:38 UTC