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 4765 - [XQX] normalization of <xqx:attributeValue> element in <xqx:attributeConstructor> different for equivalent documents
Summary: [XQX] normalization of <xqx:attributeValue> element in <xqx:attributeConstruc...
Status: CLOSED INVALID
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XQueryX 1.0 (show other bugs)
Version: Recommendation
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Jim Melton
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-06-26 15:41 UTC by Oliver Hallam
Modified: 2007-08-30 09:15 UTC (History)
0 users

See Also:

Attachments

Description Oliver Hallam 2007-06-26 15:41:15 UTC 
According to the attribute-value normalization rules, the following elements give different attribute values:

<xqx:attributeConstructor>
  <xqx:attributeName>attr</xqx:attributeName>
  <xqx:attributeValue>	</xqx:attributeValue>
</xqx:attributeConstructor>

<xqx:attributeConstructor>
  <xqx:attributeName>attr</xqx:attributeName>
  <xqx:attributeValue>&#x9;</xqx:attributeValue>
</xqx:attributeConstructor>

In the first case the tab (#x9) character in the value of the attribute is normalized to a space (#x20), whereas in the second case a tab character is inserted in the constructed attribute value.

However, these two xml fragments are identical by the rules of XML canonicalization, and so should have a single interpretation.

This is exhibited in the XQTS test cases Const-attr-ws-*.
Comment 1 Oliver Hallam 2007-06-28 09:18:03 UTC 
Just to clarify, the contents of the first <xqx:attributeValue> should be a single tab (#x9) character (this was converted to spaces by bugzilla).
Comment 2 Jim Melton 2007-08-14 15:52:45 UTC 
Thanks for your comment.  However, this difference was a deliberate decision by the Working Groups.  Accepting the argument (made in a previous bug report at http://www.w3.org/Bugs/Public/show_bug.cgi?id=3446) that a user might want to make the distinction, the WGs made the choice to differentiate. 

Consequently, I am marking this bug as resolved (INVALID) and ask that you mark it CLOSED at your earliest opportunity,
Comment 3 Andrew Eisenberg 2007-08-14 20:17:40 UTC 
I'd like to add a further explanation to Jim's response.

Both of the fragments that you've provided will produce attr="&#x9;" when the XQueryX stylesheet is applied.

The XQueryX generated for some of the Const-attr-ws-* test cases was likely incorrect until I applied a fix a week or so ago.

Let's consider Constr-attr-ws-2:

(: Name: Constr-attr-ws-2 :)
(: Written by: Andreas Behm :)
(: Description: Attribute normalization tab :)

<elem attr="	"/>


The XQueryX generate for this is now includes the following fragment:

          <xqx:attributeConstructor>
            <xqx:attributeName>attr</xqx:attributeName>
            <xqx:attributeValue> </xqx:attributeValue>
          </xqx:attributeConstructor>

The tab in the XQuery has become a space in XQueryX, so that both will generate the same result.


Now consider Constr-attr-ws-5:

(: Name: Constr-attr-ws-5 :)
(: Written by: Andreas Behm :)
(: Description: Attribute normalization char ref &#x9; :)

<elem attr="&#x9;"/>


The XQueryX generate for this is now includes the following fragment:

          <xqx:attributeConstructor>
            <xqx:attributeName>attr</xqx:attributeName>
            <xqx:attributeValue>&#x9;</xqx:attributeValue>
          </xqx:attributeConstructor>

Again, both the XQuery and XQueryX will produce the same result.
Comment 4 Oliver Hallam 2007-08-30 09:15:10 UTC 
Thanks, that has made it clearer.