W3C home > Mailing lists > Public > xmlschema-dev@w3.org > March 2005

Re: normalized enumeration facet values

From: Kasimier Buchcik <kbuchcik@4commerce.de>
Date: Wed, 16 Mar 2005 11:13:32 +0100
Message-ID: <423806CC.700@4commerce.de>
To: "Henry S. Thompson" <ht@inf.ed.ac.uk>
CC: xmlschema-dev@w3.org

Henry S. Thompson wrote:
> Kasimier Buchcik <kbuchcik@4commerce.de> 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

>><?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>
>><?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
> 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

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

Thanks & regards,

Received on Wednesday, 16 March 2005 10:14:05 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:56:07 UTC