Re: [ubl-ndrsc] Release Note Wording: Extensions and Ur

[Eduardo Gutentag <eduardo.gutentag@sun.com>]

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