[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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"
Powered by eList eXpress LLC