Re: [ubl] Draft 2.0 Schemas with Currency Codes edited to unions

[jon.bosak@sun.com]

OK, let's take it from the top.

In Ottawa, we decided on the following:

/=================================================================
| 3. We take a radically different view of the problem by
|    distinguishing between two kinds of code lists:
| 
|    a. Code lists that define codes used only in UBL (status
|       codes, for example).  Such lists are typically
|       well-defined, are completely under our control, and are
|       not (or should not be) extensible.
| 
|    b. Code lists that are defined by outside agencies and
|       referenced in UBL.  These are conceptually distinct from
|       the first category even if some happen to be bundled into
|       the UBL package.
| 
|    Making this distinction would allow us to take two different
|    approaches to code list definition.  Code lists of the first
|    kind could be defined in schema modules using enumerations
|    just as we do in 1.0.  Code lists of the second kind could
|    be defined in XML instances of a standard code list schema,
|    with the codes of this kind declared as unrestricted
|    strings.  Ordinary XSD validation would be used for the
|    first kind of code list, just as in 1.0, whereas validation
|    of the second kind would typically take place in a second
|    validation phase using something like Schematron.
\=================================================================

Note in particular the last sentence above.  The idea was to
preserve exactly the same kind of validation of those code lists
that we define (class "a" above) that we had in UBL 1.0.

I thought that what Marty was working on was making minor changes
to the 1.0 code list format in order to capture metadata added in
the genericode schema.  I didn't realize that his latest proposal
would defeat XSD validation of the enumerated code list values.
In retrospect, this seems pretty obvious, so I owe Marty and the
rest of the TC an apology for not catching it in last week's
discussion.  The fact remains, however, that this latest design is
not consonant with the decisions we arrived at in Ottawa.

What I need now is an assessment of how far away we are from a
format for the enumerated UBL 2.0 code list schemas that captures
all the metadata information but preserves XSD validation of the
enumerated values.  This is what we have to have *this week* (in
addition to a rollback of the relevant NDR section to what we had
before) so that we can start generating schemas.

Can anyone tell me what remains to be done in order to produce the
validatable schema format for enumerated code lists?  Is it as
simple as removing the union of token and enumeration from Marty's
latest proposal?

Jon