OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-lcsc message

[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