W3C home > Mailing lists > Public > public-xsd-databinding@w3.org > February 2006

ISSUE-8: MUST allow pattern on all types

From: <Paul.V.Biron@kp.org>
Date: Tue, 21 Feb 2006 11:49:16 -0800
To: public-xsd-databinding@w3.org
Message-Id: <OF009462DF.E116C459-ON8825711C.0068076A-8825711C.006CDC84@KP.ORG>

I thought I had posted something on this issue a long time ago...but a 
quick check of the archives didn't turn anything up.  So, here goes.

I completely recognize the problem the schema spec created by allowing the 
pattern facet on non-string types...and I argued against it during the 
development of that spec.

However, the databinding spec can NOT disallow this because the following 
is a very useful type  that uses pattern on a numberic type:

<xs:simpleType name='oddIntegers'>
        <xs:restriction base='xs:integer'>
                <xs:pattern value='[\-+]?\d*[13579]'/>

There is no other way to define the type whose value space is "the odd 
integers" and I'm told that such types exist in schemas-in-the-wild.

So, serializers just need to become smarter than they currently are.  Yes, 
it is real pain to have to serialize pathological cases like:

<xs:simpleType name='myInt'>
        <xs:restriction base='xs:integer'>
                <xs:pattern value='(0+|23[284]+)?\d*'/>

that are no problem at all for validation.

But again, this WG is NOT about changing the schema spec...it is about 
helping binding tools support the schema spec as it exists.  I am all for 
this WG educating schema authors about the difficulties they cause binding 
tools when they create pathological cases like myInt above...but to 
disallow them is not within our charter.

Also note, the serialization problems caused by pattern are not restricted 
to the numeric types (which is why I always say "non-string types"). 
Technically gYear, etc. are not numeric types but that have all the same 
problems as integer.  Don't forget that pattern on the binary types is 
also problematic!  But again, it's allowed by the schema spec!

Received on Tuesday, 21 February 2006 19:49:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:58:12 UTC