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

[Eduardo Gutentag <eduardo.gutentag@sun.com>]

Thanks for sharing your thought process with us, fascinating ;-)


On Thu, 2003-01-16 at 11:22, Burcham, Bill wrote:
> 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?
-- 
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