Re: normalized enumeration facet values

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?

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

> XSV (I'm not sure if it just fails due to the bug):

Yes, but my locally patched version also fails.

ht
-- 
 Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
                     Half-time member of W3C Team
    2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
            Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                   URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]

Received on Wednesday, 16 March 2005 09:27:18 UTC