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

[niels rasmussen <rasmus@netrover.com>]

William Kammerer wrote:

>Niels Rasmussen suggested that components in ebXML possibly be tagged to
>reflect an EDIFACT heritage (or, more accurately, "baggage").  For
>example, if the data to be expressed as the Estimated date of arrival
>were July 14, 2000, EDIFACT would represent it in the DTM segment as
>DTM+132:20000714:102'.  DTM is the segment tag for Date/Time/Period.
>The '132' is the Date/time/period function code qualifier meaning
>"Arrival date/time, estimated", and the '102' is a Date/time/period
>format code which means "20000714" is to be interpreted as "CCYYMMDD".
>Niels' suggested an ebXML tagging such as
>"DATE_20000714_EstimatedArrival_CCYYMMDD."


What I tried to do was, in part, to make two points:

(a) 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

(b) 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

In part I was posing a question and at the same time attemptin an answer by
giving the example above, to which I am not strongly committed:

- Can the equivalent of a composite data element be constructed in XML?

It is the CONCEPT of the composite data element (as implemented in the DTM
segment) that is important, NOT the actual EDIFACT or X12 codes and tags.

Regards,

Niels Rasmussen
Ottawa, Canada

Tel: +1 613-596-1454
E-mail: rasmus@netrover.com


>
>XML Tagging based on EDIFACT and X12 composite, element and segment
>names is a popular technique to investigate, though I don't know if the
>investigations have ever led to useful or useable products.  I think an
>isomorphic representation of EDIFACT in XML tags using mechanical
>transformations may be of limited appeal, simply because there is no
>real value-add provided by XML.  The only good thing I can see coming
>out of it is that it helps people who are terrified of drag and drop GUI
>EDI mappers and would now be able to write XSLT, VB or Java code (!!!)
>to navigate through, and map, their inbound documents.
>
>Furthermore, ebXML is committed to using existing ISO and other
>international standards wherever possible.  And in the case of
>specifying dates and times, ISO 8601 - Representations of dates and
>times - trumps the DTM qualifiers anyday.  The original EDIFACT and X12
>format qualifiers were meant to convey just about any date-time format
>that a COBOL (!!!) program might use, so as to accommodate "legacy"
>applications.  Pretty much every date, time, date-time, or date range
>combination supported by the DTM is expressible by ISO 8601.
>
>So in XML, and possibly ebXML, good form might suggest something like
>
>    <EstimatedArrivalDate>20000714</EstimatedArrivalDate>
>
>Where the value is expected to be an acceptable ISO 8601 date; 20000714
>is a perfectly good ISO 8601 complete basic format date.  Alternatively,
>the extended format of 2000-07-14 would also be conformant with the ISO
>standard, and is unambiguous.
>
>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"