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

["Burcham, Bill" <Bill_Burcham@stercomm.com>]

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>