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

[Lisa-Aeon <lseaburg@aeon-llc.com>]

I have re-written the Release notes according to the emails on the subject.
Please take a look and give me the okay.  I had already given Tim the last
version and don't want to drive him totally mad giving him different
versions.

---------------------------start release----------------------

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
are/will be imported and referenced.

(2) All extensions and refinements are/will be expressed as XSD extensions
in the resulting XML schemas.

(3) The business need for extensions and refinements are/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.

(4) It is our intention to publish an "Ur Library" of XML types 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 has to do with the ability to express some types of
customizations within the capabilities of XSD syntax.

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


Those interested in further understanding of the anticipated extension
methodology should see the white papers found at the naming and Design Rules
section of the UBL portal (www.oasis-open.org).

---------------------------end------------------------------------------
----- Original Message -----
From: "Burcham, Bill" <Bill_Burcham@stercomm.com>
To: "'Eve L. Maler'" <eve.maler@sun.com>; <ubl-ndrsc@lists.oasis-open.org>
Cc: "'Tim McGrath'" <tmcgrath@portcomm.com.au>
Sent: Thursday, January 16, 2003 1:22 PM
Subject: RE: [ubl-ndrsc] Release Note Wording: Extensions and Ur


> Thesis: "full" ur-types are no more "immediately reusable" than the
"empty"
> ones.
>
> Here's the scenario: I want to specialize a UBL address by removing one
> element (say, ZIP code -- heck, does it matter?) and, say also add an
> element or two.
>
> Under the "full" ur-type scheme we have:
>
> 1. a new schema
> 2. with a new complex type
> 3. derived from the "full" ur-type "Address-ur"
> 3.a. via "restriction"
> 4. the content model contains:
> 4.a. to add an element: add a new element declaration
> 4.b. to keep an element "unaltered": we'll often (usually) need a
> redeclaration since the minOccurs=0 in the ur-type will be inappropriate.
> This'll entail copying the definition (cut/paste) from the UBL schema (not
> the ur-schema).
> 4.c  to drop an element: there is no action required -- just don't
redeclare
> it
>
> Under the "empty" ur-type scheme we have:
>
> 1. a new schema
> 2. with a new complex type
> 3. derived from the "empty" ur-type "Address-ur"
> 3.a. via "extension"
> 4. the content model contains:
> 4.a. to add an element: add a new element declaration
> 4.b. to keep an element "unaltered": we'll ALWAYS have to declare the
> element -- copying the definition (cut/paste) from the UBL schema.
> 4.c. to drop an element: there is no action required -- just don't declare
> it
>
> The two approaches differ (in this scenario) only at 4.b.  And the
> difference comes in only when the _actual_ UBL model prescribes a
> minOccurs=0.  In that case, the "full" ur-type approach is superior since
at
> 4.b. there is no work to be done under "full" (whereas under "empty" you
> have to declare the element anyway).  I analyzed the current UBL model and
> about two-thirds of our elements are minOccurs=0.  (hello Tim: time to
> normalize better :)  but I digress...) So with the current model, under
this
> scenario "full" gets the nod 2/3 of the time whereas the two approaches
are
> equal 1/3 of the time.
>
> Another, and arguably the dominant scenario is one in which we are only
> _adding_ elements -- not taking any away.  This is classic specialization.
> Under that scenario, the user simply extends the UBL schema.  Both "full"
> and "empty" approaches are equivalent.
>
> And now I've come full circle and convinced myself that "full" is better
> than "empty".  My thesis is blown.  I hope you have enjoyed this tour of
my
> tortured thought process.  Thank you for playing.  Be sure to see the
young
> man in the red blazer as you exit the building, for your free parting
> gift...
>
> -Bill
>
> -----Original Message-----
> From: Eve L. Maler [mailto:eve.maler@sun.com]
> Sent: Thursday, January 16, 2003 9:05 AM
> To: ubl-ndrsc@lists.oasis-open.org
> Subject: Re: [ubl-ndrsc] Release Note Wording: Extensions and Ur
>
>
> I hate to say this and find out I'm wrong, but...  Though we didn't do a
> formal vote, I thought we had reached consensus in Minneapolis on
> "full".  It was proposed in the first place as an improvement over
> "empty" that is immediately usable to customizers without extra
> application layers and gives interop benefits.
>
> Eve
>
> Burcham, Bill wrote:
> > 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?
>
> --
> Eve Maler                                        +1 781 442 3190
> Sun Microsystems                            cell +1 781 354 9441
> Web Technologies and Standards               eve.maler @ sun.com
>
>
> ----------------------------------------------------------------
> 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>
>


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.441 / Virus Database: 247 - Release Date: 1/9/2003