[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC