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

RE: xs:choice support

From: <paul.downey@bt.com>
Date: Fri, 21 Apr 2006 15:43:19 +0100
Message-ID: <2A7793353757DB4392DF4DFBBC95225504BFE900@I2KM11-UKBR.domain1.systemhost.net>
To: <petexmldev@tech-know-ware.com>, <edday@obj-sys.com>, <Paul.V.Biron@kp.org>
Cc: <gcowe@origoservices.com>, <public-xsd-databinding@w3.org>, <public-xsd-databinding-request@w3.org>

> I agree with Ed and Paul here.  Support for xs:choice seems fundamental. 
> You could offer some advice along the lines of "You may wish to check that 
> your tool supports xs:choice.  If it does not, you may wish to choose 
> another tool!"  

That's OK for someone taking a schema to build a client or a service
who has control over the toolkit employed, but not at all helpful for the 
author of a schema or WSDL wanting to reach a wide marketplace of tools 
selected by potential customers.

> However, I wouldn't advice against using xs:choice in schemas.

I propose we consider:

0) no pattern for xs:choice

1) include 'choice' as a Basic pattern with a 
design consideration - we can treat desgin considerations as
"warnings" rather than errors.

2) offer an a alternative pattern for choice:

  <element name="optionA" ../>
  <element name="optionB" ../>
  <element name="optionC" ../>


  <element name="optionA" minOccurs="0" ../>
  <element name="optionB" minOccurs="0" ../>
  <element name="optionC" minOccurs="0" ../>

Some empirical testing with toolkits might help here,
If it is only one old version of a toolkit which bails/ignores
choice, then we can provide a pattern for choice without (1),
otherwise I'd suggest a combination of (1) and (2), or (2) alone.

Received on Friday, 21 April 2006 14:43:28 UTC

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