[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: email@example.com [mailto:firstname.lastname@example.org] Sent: Wednesday, 14 April 2004 12 45 To: email@example.com Cc: firstname.lastname@example.org; gkholman@CraneSoftwrights.com Subject: [ubl] Re: [ubl-clsc] Groups - wd-ublclsc-codelist-20040414.doc uploaded Resending with unmunged subject line... [email@example.com:] | 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.