I guess I should explain my issue with DTD now. It isn't DTD per se, as much as it is global element declarations that are the problem. UBL doesn't use global element declarations (much), so examples that use them end up specifying structures that differ in important ways (from UBL ones). The particular flavor of the differences plays heck with e.g. our whole container debate. The main issue is that there is no way using element declarations to support reuse of an element in two different content models without incurring an extra level of container. For example, if I wanted to model a structure with RejectedOrderItem and AcceptedOrderItem and all I had was this: <!element orderitem (item, quantity)> My instance document would have to look like this: ... <RejectedOrderItem> <orderitem> <item/> <quantity/> </orderitem> </RejectedOrderItem> <AcceptedOrderItem> <orderitem> <item/> <quantity/> </orderitem> </AcceptedOrderItem> ... Notice how the <orderitem> tag had to occur in the instance document -- a superfluous level of nesting from the UBL standpoint, whereas if I defined orderitem as an XSD (complex) type: <xs:complexType name="orderitem"> <xs:sequence> <xs:element name="item"/> <xs:element name="quantity"/> </xs:sequence> </xs:complexType> A valid instance document could look like this: ... <RejectedOrderItem> <item/> <quantity/> </RejectedOrderItem> <AcceptedOrderItem> <item/> <quantity/> </AcceptedOrderItem> ... Since <RejectedOrderItem> and <AcceptedOrderItem> are each of type "orderitem". I don't believe that we as a group are uniformly cognizant of this issue. This fact is evidenced by our repeated and continued wrestling with it over the past year. That's why I think it's just a lot clearer to just use XSD, and further, to use XSD complex types to represent ABIE-like-thingies, as opposed to global element declarations to represent ABIE-like-thingies. Regards, Bill