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

Re: ISSUE-9: union pattern for pending document

From: Pete Cordell <petexmldev@tech-know-ware.com>
Date: Thu, 15 Jun 2006 16:32:14 +0100
Message-ID: <000e01c69090$e5cb3cb0$ae00a8c0@RW>
To: <paul.downey@bt.com>, <peter.hendry@capeclear.com>
Cc: <jon.calladine@bt.com>, <public-xsd-databinding@w3.org>

For the record, personally I don't think xs:union is a basic pattern!  In a 
sense it is a choice keyed off of the type.  If there are doubts about 
xs:choice being a basic pattern, I can't see how xs:union can be a basic 

(We actually bundle any union data, irrespective of type, into a UTF-8 
string and let the app sort it out. {Not too difficult if it's either an 
integer or a string enumeration for example.}  I know of other tools that do 
this also; or at least they used to.  Haven't checked lately.  This approach 
could be the minimal basic solution.)


(P.S.  Actually I think xs:choice should be a basic pattern, but that's 
another issue!)
Pete Cordell
Tech-Know-Ware Ltd
                         for XML to C++ data binding visit
                         (or http://www.xml2cpp.com)

----- Original Message ----- 
From: <paul.downey@bt.com>
To: <peter.hendry@capeclear.com>
Cc: <jon.calladine@bt.com>; <public-xsd-databinding@w3.org>
Sent: Thursday, June 15, 2006 4:14 PM
Subject: RE: ISSUE-9: union pattern for pending document

On 15 Jun 2006, at 13:12, Peter Hendry wrote:

> So during unmarshalling first xs:string would be
> tried (which would always match) and xs:date would
> not be tried. xs:date could only be matched
> if xsi:type was present.


> Is it worth pointing a subtlety like this out?

Oh yes!

> I have seen it in a number of customer schemas
> who have subsequently changed the order once they
> are shown the light. When writing a union it is
> best to define the memberTypes from most restrictive to least.

I'm moving towards proposing one pattern for each
combination of built in types we allow in Basic Patterns
and/or adding a design consideration around this issue.

Received on Thursday, 15 June 2006 15:32:43 UTC

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