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

[Matthew Gertner <matthew.gertner@acepoint.cz>]

To me the more substantial point is that interoperability between types
derived directly from the Ur-Types will be better if they are "full".
Otherwise, my MattAddress might contain mostly the same fields as
BillAddress (but not all the required fields of the UBL AddressType, or
presumably we would be deriving directly from that), yet there would be
no possibility for information sharing since the supertype is empty (and
thus the common fields cannot be identified by a schema-aware
processor).

Thus:
1) Full is correct, as Bill also concludes.
2) Bill, you need to get more sleep. :-)

Cheers,
Matt

> -----Original Message-----
> From: Eduardo Gutentag [mailto:eduardo.gutentag@sun.com]
> Sent: Friday, January 17, 2003 12:59 AM
> To: Burcham, Bill
> Cc: 'Eve L. Maler'; ubl-ndrsc@lists.oasis-open.org; 'Tim McGrath'
> 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
> 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>