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

[Burnsmarty@aol.com]

Jon,

 

Some comments and questions in line:

 

In a message dated 3/15/2004 11:51:02 AM Eastern Standard Time, jon.bosak@sun.com writes:

- There are doubts in the XML expert community about the wisdom
   of using XSD substitution groups in general

What are the specific questions raised about this and to what do they pertain?

- We suspect that there may be parsers in current use that don't
   support substitution groups (though I don't think we've
   confirmed this)

I understand this is being checked today by LMI.

- Some people in UBL are firmly of the opinion that substitution
   groups are unacceptable for business use

It would help if we all could see the issues that are being raised. So far none have been in the emails on this subject these several weeks. What may be unsuitable as an unregulated practice might be just fine if used according to as set of UBL rules. There are many features of XMLSchema and other languages for that matter that require adherence to conventions not directly represented in the expression language -- for instance core component types and naming rules.

- Some other people in UBL are not quite so firm in opposition
   but are not comfortable with the idea of ad hoc additions to a
   schema even though we are well aware that many users consider
   ANY a feature

The specific proposals on the table are anything but ad hoc. All extensions must be made using declared namespaces and are explicitly testable in parsers. These proposals were first introduced to ubl in April of 2003.

- The NDRSC long ago considered the use of substitution groups
   and ruled them out of play for 1.0, so introducing them at this
   point will require an exception for code lists; this is not
   impossible, but it would require us to revisit the rationale
   for excluding substitution groups and explain why that
   rationale does not apply in the case of code lists

Would like to see the rationale and whether usage in codelists only would be inconsistent with it.

- We have not been able to confirm that the mechanism proposed
   for code lists can be implemented in constraint languages other
   than XSD (W3C), in particular ASN.1 (ITU) and RNG (ISO)

I would point out here that the normative design for the other language mappings should be the requirements and the data model (CLSC Specification sections 2 & 3). The XMLSchema representation of code lists tries to reflect this abstract model with fidelity (section 4). The other mappings should as well. Therefore, I suggest that the question to ask is can  ASN.1 (ITU) and RNG (ISO), etc... represent the requirements of the model, as does the XMLSchema mapping. If the answer is yes, as I suspect, then lossless interconversion is possible.

- Stephen Green has proposed a plan for implementing code lists
   in a way that avoids the use of substitution groups for 1.0 but
   allows for this method to be included in 1.1 without breaking
   backward compatibility with 1.0 instances:

      http://lists.oasis-open.org/archives/ubl/200403/msg00086.html
      http://lists.oasis-open.org/archives/ubl/200403/msg00095.html

If Stephen is right, then clearly the only prudent course of
action is to adopt his solution and consider the addition of
substitution groups for code lists in 1.1 when we have resolved
the uncertainties listed above.  So the question of the day is
whether Stephen's approach will work.  If no one can show him
wrong by the time we discuss this Tuesday (7-9 a.m. California
time) then I'm going to have no choice but to strongly urge what
on the face of it appears to be the safest course of action.

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.

 

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.

 

Hope this helps,

 

Marty