OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ndrsc message

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


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


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

-- 
Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 354 9441
Web Technologies and Standards               eve.maler @ sun.com



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


Powered by eList eXpress LLC