Re: [ubl-ndrsc] NDR Review - Section 7.7

[Dan Vint <dvint@acord.org>]

At 01:39 PM 1/8/2004 -0500, Eve L. Maler wrote:
>But beyond that, I think it's a little weird to actually forbid choice 
>groups.  It feels a little like "All that is not mandatory is 
>forbidden".  It's certainly going to be more rare in business documents 
>than in prose documents; perhaps a need for it will pop up in catalogs, 
>which are a hybrid?...  I believe the main reason UBL doesn't have *any* 
>choice groups to date is that its chosen methodology and spreadsheet 
>encoding have no way to accommodate it.  But I can certainly imagine ways 
>for them to do so, if the need arose.

It may also just be a matter of maturity of the UBL schema. In the ACORD 
schemas we started out with out choices, but over time we had to add them 
as we found that not everyone had the same data or that the world was not 
perfect. For instance we have code lists used for countries, regions, etc. 
We based those on the ISO or industry lists. Well we found that there might 
be instances where the world changed faster than the list - so we allowed 
an element with the code list and OR'd it with a similar element that 
allowed the name to be spelled out when a value didn't exist in the list. 
We also had situation with our insurance data where we wanted a birth or 
purchase date. We made these full year, month, day dates. Problem was that 
even though this was a correct definition of such an activity, many times 
people may only have the year, or year and month. So again we introduced an 
element for these variations, but OR'd them together to keep from having 
someone fill out all the variations (and to keep the question of "which one 
do I use?" from occurring).

We don't have many of these situations, but we do have enough to say that 
xsd:choice should not be ruled out.

With xsd:all (which is also cited) there are practical problems with using 
that make it easy to justify ruling out its use.

..dan