MHonArc v2.5.2 -->
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
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?
Seems like the right approach to me.
> 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.
Not sure I understand. Could you expand pls.
Mark
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC