RE: [ubl] Substitution Groups - Use 'em or lose 'em?

["Vint, Dan" <DVINT@acord.org>]

I haven't been following all of your requirements on code lists, but it
does seem to make some sense. It is especially useful for folks with
legacy systems that already manage the codes and their validation or
where you have a quirk like ours where we have two different code list
definitions:

Closed lists mean you should reject the message always if there is a
code value that is not part of the standard.

Open lists (most of ours) means that you might get a code value you
don't recognize and you should not reject the message just because of
this. 

With open lists we get in trouble with the extensions because there is
no way to express our design as well as have the schema check the code
values - we want our cake and eat it to. So although we recommend that
people not edit our schema directly in previous versions, we are setting
up our next major version up to have a schema file with nothing but the
code values that they can edit and keep up to date without having to
deal with all the element and type definitions.

..dan

> -----Original Message-----
> From: jon.bosak@sun.com [mailto:jon.bosak@sun.com]
> Sent: Tuesday, August 30, 2005 10:10 AM
> To: ubl@lists.oasis-open.org
> Subject: Re: [ubl] Substitution Groups - Use 'em or lose 'em?
> 
> [DVINT@acord.org:]
> 
> | some of our members did not want the schema to validate the codes,
> | they wanted to do this in there own application. So these folks
> | will just use this base schema for their processing.
> 
> I'm coming to believe that this is the use case we should be
> designing for.
> 
> Jon
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php