[Bug 1336] please make value comparison clearer

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





------- Additional Comments From fsasaki@w3.org  2005-05-20 11:06 -------
(In reply to comment #3)
> (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.
> 
> 

Let's use a different document instance:

<person name="Dr.&#x20;&#x20;&#x20;No"/>

and the query:

string($myDoc/person/@name) eq "Dr. No"

and a schema which defines the type of @name as a simple type with a white space
facet, see
http://www.w3.org/TR/xmlschema-2/#rf-whiteSpace

If the value of the facet is "collapse", the result of the query will be true.
If there is no schema, it will be false. Please correct me if this is a wrong
example; I'm making it because white space is an important issue in i18n related
processing, and it is important to make the influcence of typing to whitespace
handling clear.

Received on Friday, 20 May 2005 11:06:46 UTC