[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ubl-lcsc] RE: [ubl-ndrsc] Functional Dependency and Normalization paper
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 -----Original Message----- From: Eve L. Maler [mailto:eve.maler@sun.com] Sent: Tuesday, September 10, 2002 10:23 AM To: 'ubl-ndrsc@lists.oasis-open.org'; 'ubl-lcsc@lists.oasis-open.org' Subject: Re: [ubl-lcsc] RE: [ubl-ndrsc] Functional Dependency and Normalization paper 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC