[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ubl-ndrsc] Release Note Wording: Extensions and Ur
I'll reiterate the concern I raised in the phone con yesterday: there are two proposals for solving the problem here and both involve a library of ur-types. The old proposal (paella) proposes an ur-type library of empty types (names only), the newer proposal prescribes an ur-type library of "full" types (where each element of each type is optional). Until we've debated the pros/cons of empty vs. full, can we change the description to something like: (4) XSD derivation does not allow certain types of operations, such as creating a derived type with optional content that was required in the base type. Because these operations might be needed in real-world business implementations of UBL, a top-level or "Ur" library of types will be created in a separate namespace, mirroring the UBL library. The UBL library will be derived from this Ur Library, which will also be available to UBL implementors when they need to create a type that cannot be derived directly from one of the UBL types. (I just removed "but with all content models containing only optional elements and attributes"). Is that ok? -----Original Message----- From: Matthew Gertner [mailto:matthew.gertner@acepoint.cz] Sent: Thursday, January 16, 2003 4:01 AM To: Eduardo Gutentag; Eve L. Maler Cc: ubl-ndrsc@lists.oasis-open.org Subject: RE: [ubl-ndrsc] Release Note Wording: Extensions and Ur Yes, my biggest comment is also that the last item will be unclear to those who have not been privy to our discussions about Ur-Types. I would recommend the following phrasing (assuming the thing has not yet been frozen): (4) XSD derivation does not allow certain types of operations, such as creating a derived type with optional content that was required in the base type. Because these operations might be needed in real-world business implementations of UBL, a top-level or "Ur" library of types will be created in a separate namespace, mirroring the UBL library but with all content models containing only optional elements and attributes. The UBL library will be derived from this Ur Library, which will also be available to UBL implementors when they need to create a type that cannot be derived directly from one of the UBL types. Still a bit opaque, perhaps, but might be clearer to the uninitiated than the original version. Matt > -----Original Message----- > From: Eduardo Gutentag [mailto:eduardo.gutentag@sun.com] > Sent: Thursday, January 16, 2003 5:58 AM > To: Eve L. Maler > Cc: ubl-ndrsc@lists.oasis-open.org > Subject: Re: [ubl-ndrsc] Release Note Wording: Extensions and Ur > > The mention of a "Ur-Library" will result in a lot of head-scratching. > How about calling it a "proto-library"? It may be more understandable > to most people. > > On Wed, 2003-01-15 at 11:35, Eve L. Maler wrote: > > This looks great to me, with the following suggested changes: > > > > Arofan Gregory wrote: > > > Folks: > > > > > > Below please find proposed wording for inclusion in the Release Notes > > > accompanying the LCSC package. > > > > > > Cheers, > > > > > > Arofan > > > > > > > ________________________________________________________________________ __ > __ > > > ________ > > > > > > > > > A Note on the UBL Extension Methodology > > > _______________________________________ > > > > > > The UBL TC has not yet come to a final decision on all the details of > the > > > extension methodology to be followed by those using and customizing > the UBL > > > core libraries. It is anticipated that there will be a need for users > to > > > customize the core library, however, and much work has been done in > this > > > area. The following points should be borne in mind during review of > this UBL > > > Library release, as being probable features of future releases: > > > > > > (1) All customizations (extensions and restrictions) will utilize XML > > > namespaces owned by the customizing user, into which the core UBL > libraries > > > will be imported and referenced. > > > > > > (2) All extensions and refinements will be expressed as XSD extensions > in > > > the resulting XML schemas. > > > > Regarding the use of "will" in the two points above: These are actually > > recommendations/guidelines we'll be making, right? So effectively these > > will eventually be "musts" or "shalls" or something in our real CM > > rules. But for the purposes of this note, it might sound better and be > > less likely to be misinterpreted if we say "We are/will be recommending > > that...", or something similar. > > > > > > > > > > (3) The business need for extensions and refinements will be described > using > > > a "context mechanism" based on that found in the UN/CEFACT Core > Components > > > Technical Specification, and earlier in the ebXML Core Components > work. This > > > mechanism provides for a rules language that lets machines determine > the > > > appropriateness of a specific extension for a given business purpose. > > > > Same comment on "will" here -- I think but I'm not sure. The "business > > need" part is a little confusing. > > > > > > > > (4) An "Ur Library" of XML types will be published in future as part > of the > > > UBL deliverables, in its own set of namespaces, from which everything > in the > > > UBL library will itself be a refinement. This should have little or no > > > effect on the direct use of the document types and components found in > this > > > library release - they will have the same types and names - but will > affect > > > how they are expressed in the schemas. The reason for having such a > > > mechanism have to do with the ability to express some types of > > > customizations within the capabilities of XSD syntax. > > > > Here, "will" means "Our intention is to...", right? Good reason to > > avoid "will" above, then. > > > > Second to last line: s/have/has/ > > > > > > > > Those interested in further understanding of the anticipated extension > > > methodology should see the whitepapers found at the naming and Design > Rules > > > section of the UBL portal (www.oasis-open.org). > > > > Change "whitepapers" to either "white papers" or "position papers". > > > > Eve > -- > Eduardo Gutentag | e-mail: eduardo.gutentag@Sun.COM > Web Technologies and Standards | Phone: +1 510 550 4616 x31442 > Sun Microsystems Inc. | 1800 Harrison St. Oakland, CA > 94612 > W3C AC Rep / OASIS TAB Chair > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC