Re: [ubl-ndrsc] Code lists: discussion kickoff

[Doug Bunting <dougb62@yahoo.com>]

I'll add a few additional comments, mostly to expand upon what Eve has said below.

This document currently seems to be focused on intermediate elements, those
containing other information and of some aggregate type defined elsewhere.  I agree
that such elements may either include a "role" element or attribute to disambiguate
its meaning or be named more explicitly.  I also agree the second approach helps with
required vs. optional constraints when they apply to particular roles.  I don't agree
this is the only code list issue worth discussing.

As Eve describes, we have some additional issues to resolve with respect to external
code lists.  How are internal and external code lists combined and disambiguated (and
when are such combinations appropriate)?  Should we make any recommendations about
versioning the external code lists, identifying the version used in an instance and
changing the version used without modifying the schema?  If a recipient does not
recognize an external code list, should the instance provide any information helpful
in finding information about that list or should this be an error?  Is schema
validation of external code list values ever a requirement?  Should our schema
include snapshots of external code lists to reduce reliance on external groups making
changes independent of our releases?  Should our schema include machine verifiable
lists of code lists values for those external groups not yet using schema?  Do copy
write issues crop up almost immediately?  How should an external code list value be
identified in an instance (say, org, list type and value)?  How is that information
structured and constrained (URI values as Eve suggests below are one possibility,
though few external groups are paying any attention to creating such namespaces)?

Additional issues may come from elements requiring a "role set".  For example, a
Party might be identified once in a document but the instance may inform the
recipient that party acts as Supplier, Shipper and Logistics Provider (probably not
real EDI role names).  In such cases, is it necessary to repeat all of the details
about the same Party multiple times within well-named intermediate wrappers?

I'm not sure it's an issue but are there cases where code lists may be used apart
from property terms?  Such cases may result in additional issues.

thanx,
    doug

"Eve L. Maler" wrote:

> We're going to need to decide the issues surrounding "code lists" very
> soon.  Mike's position paper is here:
>
> http://www.oasis-open.org/committees/ubl/ndrsc/pos/draft-Rawlins-codelists-01.doc
>
> Here are a few unorganized thoughts to get the discussion going; everyone,
> please respond with your thoughts, and I'll try to formulate votable
> questions as we go:
>
> I think we may have more issues at stake here than just choosing
> "enumerations of the xsd:string type" vs. "one element per code list
> value".  Here are some issues I can think of:
>
> - 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?
>
> - 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>
>
> - 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.
>
> - 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?
>
> It would be great to see some of these additional issues spun out in the
> next rev of the position paper.
>
> Finally, regarding the "enumerations of the xsd:string type" vs. "one
> element per code list value" choice itself, I'm not sure I buy the argument
> that the latter is better.  It could potentially swell the number of UBL
> elements by orders of magnitude, and the infrastructure needed to document
> and manage elements would seem to outweigh the benefits for these little
> values.
>
>         Eve
> --
> Eve Maler                                    +1 781 442 3190
> Sun Microsystems XML Technology Center   eve.maler @ sun.com
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>