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] Re: [ubl-clsc] Groups - wd-ublclsc-codelist-20040414.do cuploaded


> I propose that this section be changed to read as follows:

If that's formal proposal, I second it.

If not, then I simply agree...

Mike Grimley

-----Original Message-----
From: jon.bosak@sun.com [mailto:jon.bosak@sun.com] 
Sent: Wednesday, 14 April 2004 12 45
To: ubl@lists.oasis-open.org
Cc: burnsmarty@aol.com; gkholman@CraneSoftwrights.com
Subject: [ubl] Re: [ubl-clsc] Groups - wd-ublclsc-codelist-20040414.doc uploaded

Resending with unmunged subject line...

[stephen_green@seventhproject.co.uk:]

| Regarding the CLSC document, lines 34 and following read, "...a 
| substitution group mechanism required for extensibility in the 
| XMLSchema mapping, that while not formally adopted for 1.0, will be 
| the bedrock for future 1.1 initiatives in this area"
| 
| Certainly "..will be the bedrock for future 1.1 initiatives in this 
| area.." is out of line with my recollection of the agreement.
| It was agreed that we'd make looking at it a high priority for 1.1, so 
| it mustn't be said at this stage whether it "will be the bedrock for 
| future 1.1 initiatives". That remains to be considered.

Stephen is correct.

The use of XSD substitution groups is highly controversial in XML technical circles and has been since they were introduced into XSD.  Even the person who originally proposed them has doubts.
It's not clear how a code list extension implemented using substitution groups would be implemented in alternative schema representations, and it's an open question whether this is the right way to provide for code list extensibility even within XSD.
In addition to the technical questions, there are people who feel strongly that substitution groups have no place in business schemas regardless of how elegant they might be from an engineering perspective.

Note that I am not promoting any of these views, I'm just reporting them.  The fact is that the use of substitution groups for this purpose is a religious issue and there is currently no consensus in this area.

Achieving that consensus will require a much broader process of consultation than what we've been able to accomplish so far.  I will be proposing that we institute the wider discussion needed to achieve such a consensus by using a method that proved highly successful in resolving similar religious issues in the design of XML, which is to start a public discussion on the ubl-dev list as soon as we get back from Hong Kong.  This will allow everyone interested in the issue to explore it from all angles, expose all the issues (both technical and business-related), and come to a common understanding of the problem and its possible solutions.  I hope to use a little of our time in Hong Kong preparing for this discussion.

In order to achieve acceptance of the CL draft as part of the UBL 1.0 package, therefore, it's important that we be clear on the status of the substitution group mechanism.  It's my sense that we can agree to present this mechanism as a possible solution for code list extension and one that can serve as a basis for further work in the UBL 1.1 time frame, but to present it as the only possibility for code list extension would be to go beyond what I think we can agree on for inclusion in the UBL 1.0 Committee Draft.

The section titled "1.1 About the current version" in the CL draft uploaded yesterday reads as follows:

   The Code List model described in this paper, for UBL 1.0, has
   laid much of the necessary groundwork for extensible code
   lists. It has evolved a substitution group mechanism required
   for extensibility in the XMLSchema mapping, that while not
   formally adopted for 1.0, will be the bedrock for future 1.1
   initiatives in this area. Substitution groups were not
   recommended as part of the initial release, however, their use
   is not expressly forbidden. The primary concern is that
   uniformity of the meta-data be preserved regardless of any
   extension concerns.

   In the balance of the document, a comprehensive model of code
   lists is presented. Those features that are to be finalized
   during the near term revision process after the release of UBL
   1.0 are tagged in the document as "(Future)". They appear
   in the context of their proposed use so that the entire picture
   can be shown of a code list mechanism that can meet the full
   set of requirements contributed and exposed herein.

I propose that this section be changed to read as follows:

   The Code List model described in this paper for UBL 1.0 has
   laid much of the groundwork for extensible code lists.  It
   includes an extensibility mechanism based on XSD substitution
   groups that has not been adopted for UBL 1.0 but will serve as
   a starting point for work on a code list extension mechanism
   for UBL 1.1.  The current specification places a priority on
   uniformity of code list metadata independent of the mechanism
   eventually adopted for code list extension.

   The balance of this document presents a comprehensive model of
   code list data.  Those features that are to be considered for
   adoption in UBL 1.1 are labeled "(Future)".  They appear in the
   context of their proposed use in order to present a solution
   that meets all the requirements identified herein for code
   lists, but it should be understood that they represent
   proposals as this point and are subject to change in light of
   further discussions.

   Persons wishing to engage in the further evolution of this
   specification are urged to join the OASIS Universal Business
   Language Technical Committee (http://oasis-open.org/).



To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/ubl/members/leave_workgroup.php.



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