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.doc uploaded


[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/).




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