Or how about "a library of base types from which the UBL types will derive".
Uh... Or did I just make it worse.
-----Original Message-----
From: Eduardo Gutentag [mailto:]
Sent: Wednesday, January 15, 2003 10:58 PM
To: Eve L. Maler
Cc:
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:
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>
