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

[Bug 1336] please make value comparison clearer

From: <bugzilla@wiggum.w3.org>
Date: Thu, 19 May 2005 17:30:27 +0000
To: public-qt-comments@w3.org
Cc:
Message-Id: <E1DYoqp-0003DS-Jm@wiggum.w3.org>

http://www.w3.org/Bugs/Public/show_bug.cgi?id=1336





------- Additional Comments From jonathan.robie@datadirect.com  2005-05-19 17:30 -------
(In reply to comment #2)
> (In reply to comment #0)
> > http://www.w3.org/International/2005/02/xpath-review.html Comment ID: 4
> 
> more words of explanation would not help, but an example similar to the one
> given might help. You could add that as a note.

I think that there is a misunderstanding in the original comment, and it is a
misunderstanding that involves both schema validation and our spec. Let me
explain, and I think it will be clear why adding an example won't help.

Here's the original comment:

> The value comparison relies on atomization of the values; if these
> are nodes, the atomized value is returned as a typed value. You
> should make clear that this is quite different from the comparison
> of string values. This difference might be important for some i18n
> applications. Consider the following example:
>
>   <myEl1>bla<myEl2>&#x160;</myEl2></myEl1>
>
> if there is a schema which declares the type of myEl2 as empty,
> &#x160; would not be part of the PSVI and the result of
>
> $myDoc/myEl1 eq "bla"
>
> would be true, otherwise it would be false.

Actually it is not true that this comparison can sometimes return
true, regardless of the schema (if any). There are two possibilities:

1. The element has a mixed type, is not schema validated, or schema
validation was attempted but this element did not validate. In this
case, the comparison can be made, the typed value is the string value
of the node as an instance of xdt:untypedAtomic, and the typed value
contains the &#x160; character, so the comparison returns false. This
is the case that you get wtih the schema you describe, since
validation would fail (in XML Schema, a non-breaking space is not
allowed in an empty element).

2. The element has a non-mixed type and schema validation
succeeded. In this case, atomization fails, and an error is raised.

The reason an example doesn't really help is that most people either aren't
thinking about how to sneak in non-breaking space in a way that might cause this
problem, or else they have tried it with a schema validator and learned that it
breaks validation. The example you ask for would primarily help those who have
thought about this example but never determined what XML Schema would do with it.
Received on Thursday, 19 May 2005 17:32:36 UTC

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