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