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


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>


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


Powered by eList eXpress LLC