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


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

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

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


If the latest NDR change about union of token and enumeration from Marty's
latest proposal is rolled back, no additional changes in EDIFIX are needed
to support codelists based on the August 11, 2005 NDR draft.

We can start generating draft schema as soon the PSC has another draft set
of spreadsheets. It is important to note that GEFEG still needs to review
the latest NDR draft sent yesterday by MG and determine what other
programming changes are needed to produce schema that are fully compliant. 

Can you tell us when the codelist discussion is scheduled to be finalized
and closed to further decisions? 

-----Original Message-----
From: jon.bosak@sun.com [mailto:jon.bosak@sun.com] 
Sent: Wednesday, December 07, 2005 4:00 PM
To: ubl@lists.oasis-open.org
Subject: Re: [ubl] Draft 2.0 Schemas with Currency Codes edited to unions

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?


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

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