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:
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
