Henry S. Thompson wrote:
> Kasimier Buchcik <kbuchcik@4...> writes:
> 
> 
>>I still have a question concerning a similar issue: If restricting the
>>value of the whitespace facet of the base type, what whitespace
>>value is actually used for validation, the inherited or the restricted?
> 
> 
> Should be the restricted, otherwise what's the point?

My question might have been misleading: it boils down to the question
if the current type or the base type is used to create the normalized
value of the enumeration facet. So as I understand you below, the
inherited type is used, thus the inherited whitespace facet's value is
used.

>>Example:
>>
>><?xml version="1.0"?>
>><schema xmlns="http://www.w3.org/2001/XMLSchema">
>>   <element name="foo">
>>     <simpleType>
>>       <restriction base="string">
>>         <enumeration value="hel   lo"/>
>>         <whiteSpace value="collapse"/>
>>       </restriction>
>>     </simpleType>
>>   </element>
>></schema>
>>
>><?xml version="1.0"?>
>><foo xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> >  hel lo  </foo>
>>
>>Xerces uses the inherited whitespace value for normalization:
>>
>>"(Error) cvc-enumeration-valid: Value 'hel lo' is not facet-valid with
>>respect to enumeration '[hel   lo]'. It must be a value from the
>>enumeration."
> 
> 
> That's a bug in the spec., in my opinion, with hindsight.  The
> spec. says the enumeration values must be valid (and as a consequence,
> normalized with respect to) the base type defn, not the type defn
> itself.  It's simpler that way, but at best confusing (as in your
> example) and at worst bizarre:
> 
> <simpleType>
>  <restriction base="string">
>   <maxLength value="1"/>
>   <enumeration value="xx"/>
>  </restriction>
> </simpleType>
> 
> is a legal, unsatisfiable, type definition, per the spec.
> 
> I _think_ I'd prefer to see the checking and normalization done
> against the type defn itself.

I'm with you here: I find it somehow confusing to define an enumeration
facet, plus a restricting whitespace facet, and to see the enumeration
facet's value being normalized accoring to the base type, not the
current type. Although a bit different, it feels like defining a fixed
value constraint, and see it in the value space of the according actual
type's base type.

>>XSV (I'm not sure if it just fails due to the bug):
> 
> 
> Yes, but my locally patched version also fails.

If this is just a bug in the spec, than the example should fail - and it
does with XSV. The only thing I see to be not correct is the displayed
error, reporting the "collapsed" enumeration facet's value, being the
reason why I got unsure if the "collapsed" whitespace facet - according
to the current type - was used or the inherited "preserve" whitespace
facet.

Can you foresee if this is going to be changed in XML Schema 1.1?

Thanks & regards,

Kasimier

From ht@i... Wed Mar 16 16:47:50 2005
Received: from bart.w3.org ([128.30.52.40])
	by frink.w3.org with esmtp (Exim 4.44)