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. > I see the terms linkage, relationship and association as fairly similar. In a relational model these are implemented by foreign keys, in XML by including the associated element within the container (sorry, the language gets in the way here - maybe we should just get down to diagrams!). It is just different ways to implement the same concept. Not sure i like 'explicit' and 'implicit' - we could just say that one may be more elegant. > >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. > thanks i agree - let me know how it should look. i learnt SQL in 1984 so i didn't know it had such as beast. > >Also, the attribute name "account" on the "order" relation is ambiguous. I >recommend you call it seller-account. > yes, eve had problems with this as well. we should keep the naming as simple as possible. > > >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> > thanks again. i was trying to keep in alignment with the other papers. i actually know XSD better than DTD so it is easier for me to do this. NB your example nneds some tidying up but i get the point. i know some may disagree, but i think XSD also shows the structure more meaningfully for non-SGML people. > >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. > good grief , you're right again. what i should have said was 'when the potential cardinality of the relationship is greater than 1'. > > >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. > not another constant enemy - how will i sleep at nights! > >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 > > >. > -- regards tim mcgrath fremantle western australia 6160 phone: +618 93352228 fax: +618 93352142