Re: Brave new world, OR tagging based on EDIFACT names

[jmotley@globaltechltd.com]

William,

Just two small cents on this one;

Shouldn't data types be expressed in the DTD or schema?  For example the data
element "Estimate Arrival" has a data type of DATE, or probably more
appropriately DATETIME.

Regards,
John Motley







"William J. Kammerer" <wkammerer@foresightcorp.com> on 07/18/2000 08:09:13 AM

To:   ebXML Core <ebxml-core@lists.ebxml.org>
cc:    (bcc: jmotley/Globaltechltd)

Subject:  Re: Brave new world, OR tagging based on EDIFACT names



Niels Rasmussen maintains that "Back end integration would be easier if
a data element tagging system could be devised that users would want to
use not only for transmitting data (EDI / ebXML) but also in internal
applications."

Maybe it would be easier if applications used the same tagging system as
used for B2B business data exchange. I think something like this, or
easy equivalence mechanisms between internal and external tags, is the
premise behind BSI, or Business System Interoperation.  BSI's core is "a
globally distributed set of business object repositories (BEACON) that
can be accessed via...the Internet." More information on BSI may be
obtained at http://www.cs.mu.oz.au/research/icaris/bsi.html.

Niels further penned "[the] composite data element, as used in the
EDIFACT DTM segment, is a powerful means of tagging data elements that
is flexible and yet stable.  Flexible in the sense that new data element
tags can be devised simply by adding a new code value to a table, stable
in the sense that the tag construct always remains the same."  And soft,
yet hard.

Yes, an XML element might itself contain only element content - i.e.,
be constrained to contain only child elements, like an EDIFACT or X12
composite is composed of subordinate data elements.  As an example, the
C507 Date/Time/Period composite could be represented as below.  For
those of you who don't have a copy of EDISIM - the World's leading EDI
productivity tool - handy, follow along by examining
http://www.unece.org/trade/untdid/d00a/trcd/trcdc507.htm.  And yes, I
will have an ample supply of my ever-popular business cards with the
EDISIM Standards Reference viewer mini CD-Rom with me in San Jose.

    <DateTimePeriod>
        <Function Code="132">Arrival date/time, estimated</Function>
        <Format Code="102">CCYYMMDD</Format>
        <Value>20001004</Value>
    </DateTimePeriod>

Note that with XML, what with tags for everything, there's little need
for the arbitrary element order imposed by positional EDI - I have the
function and format before the data value here (C507 would require
function, value and format code, in that order).

Alternatively, <DateTimePeriod> could be defined as mixed-content,
where the character data of the most important thing (the actual date)
is interspersed with the XML elements representing the qualifiers:

    <DateTimePeriod>
        20001004
        <Function Code="132">Arrival date/time, estimated</Function>
        <Format Code="102">CCYYMMDD</Format>
    </DateTimePeriod>

Or, <DateTimePeriod> could just have character content, and all the
qualifiers would be expressed as attributes:

    <DateTimePeriod Function="132" Format="102">
        20001004
    </DateTimePeriod>

As you can infer, there's probably a number of other permutations that
we could examine.   But, so what?  If all you're going to do is dress up
EDIFACT in XML, why not just use the real thing?

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

Visit FORESIGHT Corp. at http://www.foresightcorp.com/
"Commerce for a New World"