RE: ebXML Entity Classes - or EDIFACT is based on DBA skills andtheoryand look where it got...

[John McClure <hypergrove@olympus.net>]

I understand. Now let's translate this to XML, because the b'ers and m'ers
may have a point about using codes! In the DCN there are three parsing
environments we care about.

1. DTD-parser based encoding

<Document xsi:type='PropertyDocument' name='PurchaseOrder'>
   <list xsi:type='events' name='documentEvents'>
   <Event xsi:type='DocumentEvent' name='Received'>
      <instant value='2000-02-28'>My birthday, Feb 28th!</instant>
   </Event>
   </list>
</Document>

2. XSD-parser based encoding

<PropertyDocument name='PurchaseOrder'>
   <events name='documentEvents'>
   <DocumentEvent name='Received'>
      <instant value='2000-02-28'>My birthday, Feb 28th!</instant>
   </DocumentEvent>
   </events>
</PropertyDocument>

3. RDF-parser based encoding

<PurchaseOrder>
   <documentEvents>
   <Received>
      <instant value='2000-02-28'>My birthday, Feb 28th!</instant>
   </Received>
   </documentEvents>
</PurchaseOrder>

There is an alternative way of coding that uses an <Entry> element, but let
me save that for another day. The point I wish to share is that conventional
data analytic and semantic analytic techniques should both be applied when
crafting DTDs and namespaces. I do think that EDI segments seem but topics
(one of the DCN's 15 resource-types), so it may be useful to the EDI
community (as well as correct, technically) to represent segments more
palatably as topics that concern a particular resource-type. In the DCN, I
finally concluded that I could _not_ live without topics, because there is
too much that simply is not feasibly represented using more structured
markup.

As Chris Nelson has done with his <concept> element, using a <Topic> element
means hundreds of XML element-types can be eliminated, simplifying
stylesheets incredibly, e.g.,

<Topic xsi:type='DocumentTopic' name='Colophon'>
   <title xml:lang='EN'>Document Colophon</title>
   <content> put unstructured text or nontext here </content>
   <rdf:Description>
	<!-- put structured info here -->
   </rdf:Description>
</Topic>

Personally, I'd rather not create a stylesheet for a <Colophon> element.
What a hassle! I'd rather do a <xsl:template
match='Topic[@name="Colophon"]'>.
Regards,
John
-----Original Message-----
From: William J. Kammerer [mailto:wkammerer@foresightcorp.com]
Sent: Monday, March 05, 2001 3:25 PM
To: ebXML Core
Subject: Re: ebXML Entity Classes - or EDIFACT is based on DBA skills
andtheory and look where it got...


John McClure told Bob Miller "Surely, data-modelers can do better than
elements like <PurchaseOrderReceiptDate> -- where is the normalization?
Have all our DBA skills and theory become moot in the XML age? I think
not."

I guess "DBA skills and theory" were all the rage when UN/EDIFACT was
devised.  Regardless of the type of date, it's generally going to go
inside a DTM (Date/Time/Period) segment.  And the type of date (in this
case, Order received date/time) will be used as a qualifier.  So you
have:

        DTM+8:20000228:102'

Where 8 means "Order received date/time", and 102 says the 20000228 is a
date in the form CCYYMMDD.  The DTM allows an incredible amount of
normalization - just change the Date or time or period function code
qualifier (the 8 in this example) to any of a myriad code values
described by UN/EDIFACT data element 2005, and you can describe any kind
of date (or time or date-time) under the Sun.

But this is precisely what people bitch about when bemoaning the
complexity of EDI.  XML was supposedly going to cure these ills.

William J. Kammerer
FORESIGHT Corp.
4950 Blazer Pkwy.
Dublin, OH USA 43017-3305
+1 614 791-1600

Visit FORESIGHT Corp. at http://www.foresightcorp.com/
"accelerating time-to-trade"