Re: [ubl-lcsc] RE: [ubl-ndrsc] Functional Dependency and Normalizationpaper

["Eve L. Maler" <eve.maler@sun.com>]

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