OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ndrsc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: [ubl-ndrsc] Code lists: discussion kickoff

Title: RE: [ubl-ndrsc] Code lists: discussion kickoff
When I sent this the first time, I did not see any comments, so am resubmitting to further the discussion.
-----Original Message-----
From: CRAWFORD, Mark [mailto:MCRAWFORD@lmi.org]
Sent: Thursday, January 31, 2002 11:46 AM
To: ubl-ndrsc@lists.oasis-open.org
Subject: RE: [ubl-ndrsc] Code lists: discussion kickoff

Eve wrote -
> - Extensibility of "internal" UBL code lists: I'm not
> entirely up to speed on XSD in this regard, but is it sufficient/allowed to allow
> extension developers to derive a new type based on xsd:string that unions the
> original enumerated values with some new values of their own?
>  Would this do the trick for us?

I think we need to discuss this aspect of extensibility which I see different (albeit related) to the notion of adding elements.  At what point do extensions break the standard?

> - Ad hoc extensibility: Will there be cases where it's
> acceptable/necessary to have an escape hatch in the code list, in the CodedOther
> style?  This was a common trick in the DTD-only days:
> <ice-cream
>    flavor="other"
>    other-flavor="whatever-I-want">...</ice-cream>

Yuck!  Sounds like the old "zz" - mutually defined from X12.  We probably do need a mechanism for this. Should these extensions be the only codes that are enumerated in the schema? 

> - Inclusion of external code lists: Do these need to be
> dynamic somehow, and if so, how should we handle this in the schema code?  XSD
> never chose to solve this problem properly when it was being designed, so
> the only thing I can think of would be to use a string-based type and *not*
> constrain the values at all through the XSD layer.  Checking of values
> would have to be done as some higher business-rules layer.

Should we just avoid enumerations of existing code lists - including UBL created code lists?  One way would be to create a standard 'CodeListIdentifier' tag and a predefined UBL data values for every entry in a UBL 'list of code lists'  external code list. We could then just convey the code for a code list in one element and then identify the appropriate code from that list in a paired element - a la EDI.  We then avoid the whole messy issue of ad nauseum enumerations within the schema, and leave dynamic validation up to the Server.  Of course we would still have to tackle the issue of restrictions to external code lists.

> - Unique identification of code lists: The SAML spec has a
> couple of cases where it allows values from either its own internal code list or some
> external list in various places.  It defines its internal lists by
> attaching URIs to them, a la XML namespaces.  Should we do the same
> thing?  Should we define canonical URIs for common external
> "symbol spaces" if they don't already have URIs?


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC