MHonArc v2.5.2 -->
ubl-ndrsc message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: Re: [ubl-lcsc] RE: [ubl-ndrsc] Functional Dependency and Normalizationpaper
I agree that the paper is fantastic. There are only a few points where
I feel my understanding is fragile (mostly around the magic of turning
"account" into "seller" etc.), but with a bit of study I'm sure I can
strengthen it.
Bill, regarding whether DTDs are the enemy... I do think that
ultimately any paper we publish on this should show real XSD examples.
However, I would say that it can be extremely useful at times to make
type definition/element declaration distinction fuzzy. Think of DTD
notation as a way merely to expose the element hierarchy, which is
what's under discussion here. Introducing a new distinction can cloud
the issue, and if XSD notation is added to the paper, we'll need to
explain/defuse that indirection.
Eve
Burcham, Bill wrote:
> This is a really clear paper Tim. Your effort payed off. I believe it
> gives designers something tangible and useful on which to hang their hats.
> Here's my detailed reactions:
>
> In 1NF (in appendix A) at the point where you've found the one-to-many
> relationship between "order" and "order item" and you've shown the need (in
> the relational model) for the "linkage" from "order item" back to "order"
> via the foreign key. It seems worth noting at that point that this linkage
> is explicit in the relational model but implicit in the (eventual) XML one.
> This linkage between "order" and "order item" will be inferred from the
> context -- an "order item" is associated with the "order" under which it
> appears. We'll see this again and again.
>
> Next, I think it would help in Appendix A if in your schemas you adorned
> foreign keys in a manner similar to the way you do with primary keys, e.g.:
>
> order(PRIMARY IDENTIFIER [order number], buyer, account, order date, FOREIGN
> KEY (account, seller[account]))
> seller(PRIMARY IDENTIFIER [account], name)
> order item(PRIMARY IDENTIFIER [ order number, item number], quantity,
> FOREIGN KEY (order number, order[order number]) FOREIGN KEY (item number,
> item[ item number]))
> item(PRIMARY IDENTIFIER [item number], item description, unit price)
>
> Then again, maybe you should just use SQL-92 for this instead of our
> made-up-almost-SQL-92 language.
>
> Also, the attribute name "account" on the "order" relation is ambiguous. I
> recommend you call it seller-account.
>
> Appendix B
>
> Please do not use DTD in examples. I realize it's terse, and that's nice,
> but it continually runs us into problems. Please rephrase in (verbose) XSD:
>
> <xs:complexType name="Order">
> <xs:sequence>
> <xs:element name="OrderNumber"/>
> <xs:element name="Buyer"/>
> <xs:element name="SellerAccount"/>
> <xs:element name="OrderDate"/>
> </xs:sequence>
> </xs:complexType>
> <xs:complexType name="Seller">
> <xs:sequence>
> <xs:element name="Account"/>
> <xs:element name="Name"/>
> </xs:sequence>
> </xs:complexType>
> <xs:complexType name="OrderItem">
> <xs:sequence>
> <xs:element name="OrderNumber"/>
> <xs:element name="ItemNumber"/>
> <xs:element name="Quantity"/>
> </xs:sequence>
> </xs:complexType>
> <xs:complexType name="Item">
> <xs:sequence>
> <xs:element name="ItemNumber"/>
> <xs:element name="Description"/>
> <xs:element name="UnitPrice"/>
> </xs:sequence>
> </xs:complexType>
>
> Next, I wouldn't use the term "n-ary" to stand for maxOccurs="unbounded".
> "N-ary" is used in database lingo to refer to the "arity" of a relationship,
> e.g. if we're relating four different kinds of things then the arity is four
> and you might call the relationship a quaternary one.
>
> In the interest of eliminating superfluous issues from our discussion I feel
> like it's important to work out the rest of Appendix B using XSD instead of
> DTD. My experience is that DTD-think (a.k.a. global element think) is our
> constant enemy.
>
> Again, great paper Tim.
>
> Regards,
> Bill
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
--
Eve Maler +1 781 442 3190
Sun Microsystems cell +1 781 883 5917
XML Web Services / Industry Initiatives eve.maler @ sun.com
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC