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

["Townsie, Michael" <Michael.Townsie@den.galileo.com>]

OTA has plans to base tag names upon the context of where specific element
tags exist.  This hierarchical relationship is possible XML Schema and can
significantly reduce tag name size (which can be very critical).

How about the following:

	<arrival>
		<date estimate="Y">20000714</date>
		<place>Denver</place>
      </arrival>


Also, note that an additional date attribute (e.g. 'format') could be used
to further qualify the date element.  Or use XML namespace to specifically
qualify the date element (ref="http//ISO-8601/date-format/....").


Michael Townsie
Galileo International
303.397.5707


-----Original Message-----
From: William J. Kammerer [mailto:wkammerer@foresightcorp.com]
Sent: Friday, July 14, 2000 10:37 AM
To: ebXML Core
Subject: Re: Brave new world, OR tagging based on EDIFACT names


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."

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"