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


I'll reiterate the concern I raised in the phone con yesterday: there are
two proposals for solving the problem here and both involve a library of
ur-types.  The old proposal (paella) proposes an ur-type library of empty
types (names only), the newer proposal prescribes an ur-type library of
"full" types (where each element of each type is optional).  Until we've
debated the pros/cons of empty vs. full, can we change the description to
something like:

(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. 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.

(I just removed "but with all content models containing only optional
elements and attributes").

Is that ok?

-----Original Message-----
From: Matthew Gertner [mailto:matthew.gertner@acepoint.cz] 
Sent: Thursday, January 16, 2003 4:01 AM
To: Eduardo Gutentag; Eve L. Maler
Cc: ubl-ndrsc@lists.oasis-open.org
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>

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