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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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

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>

2. XSD-parser based encoding

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

3. RDF-parser based encoding

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

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

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>
	<!-- put structured info here -->

Personally, I'd rather not create a stylesheet for a <Colophon> element.
What a hassle! I'd rather do a <xsl:template
-----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

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


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
4950 Blazer Pkwy.
Dublin, OH USA 43017-3305
+1 614 791-1600

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC