[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ubl-ndrsc] Release Note Wording: Extensions and Ur
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC