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