ubl — archive

Re: [ubl] How UBL could postpone a decision about whether or not to implement...

From: Martin Burns
To: [email protected]
Date: Tue, 16 Mar 2004 12:26:00 -0000

MHonArc v2.5.0b2 -->

ubl message

Subject: Re: [ubl] How UBL could postpone a decision about whether or not to implement...

From: [email protected]
To: [email protected], [email protected]
Date: Tue, 16 Mar 2004 07:40:09 EST

Jon,

Thanks for your response. My comments inline:

Marty

In a message dated 3/15/2004 8:02:55 PM Eastern Standard Time, [email protected] writes:

[[email protected]:]

| I would like to see the code list model developed with the clsc
| implemented as recommended independent of whether ubl 1.0 chooses
| to exploit the extensibility model that relies on substitution
| groups. If this is done, the code list schemas will at least be
| complete as to the necessary requirements and can start being used
| in practice. ubl can then debate how best to use these
| capabilities in the rest of the schemas.

I don't know what you mean by "the rest of the schemas." We are
not considering the use of substitution groups outside of code
lists.

The key issue here is whether client schemas of the code lists inherit from currencyCodeType or use currencyCode by reference. In the former case, to extend a schema based on currencyCodeType, to say add a single new currency (without modifying ubl or third party standard code list), you would need to redefine every element of every structure that contained an element based on this type. If you choose the latter (note the word "substitution" does not appear in the ubl schemas) then only a new type that substitutes for currencyCode is needed to alter the parsing regardless of where in the schemas the code is used.

Are you suggesting a solution in which 1.0 code lists would be
published without using substitution groups in a way that would
allow this approach to be adopted later? If so, I don't
understand how your proposal differs from Stephen's.

No, I am suggesting that the CLSC code list schema be used as proposed.

| As illustrated in the example I provided to Lisa Seaburg this
| morning shows, virtually no change in the SDT schemas and higher
| aggregations are required to use code list schema without the
| extensibility feature in its complete and current form. Use of
| substitution groups in the SDT is all that is required to add the
| additional capabilities for extension and restriction.

I can't see this example. Perhaps you did not post it to the
list.

Could you please state your proposal in terms of the changes that
would need to be made to the latest set of schemas?

The attached schema set is an example of the schema form we are proposing. CLSCModifiedSpecials20040316.zip:

Contains the CLSC code list example UBL-CodeList-CurrencyCode-1.0-draft-8.1.xsd with the minimal change to UBL-SpecializedDatatypes-1.0-draft-8.1.xsd to support the change of name from derivedCode to CurrencyCode. Notice no other files were touched. The code list schema has comments in it that correlate the various components to the sections in "Howtogofromspreadsheettoschemas20040312.doc".

The instance file, invoice.xml, shows that there was no change in the resulting instance files from adding extensibility to the code list. Yet this extensibility relies on the code list schema using the CLSC model.

In addition, a modified version of UBL-SpecializedDatatypes-1.0-draft-8.1(Extended).xsd illustrates how to extend a code list in an importing schema. This file was not used as a proposal, just an easy way to insert an example of how one could apply the extensibility mechanism.

CLSCMODIFIEDSPECIALS20040316.ZIP