Re: Brave new world

[niels rasmussen <rasmus@netrover.com>]

Margaret,

Following your comments on the difficulties of integrating EDI messages
with back end applications and your observation that ebXML doesn't appear
to "solve" that issue, I would like to add my thoughts on the subject.

For a starter I believe that what is needed, whether for edi or XML, is a
data-element tagging system that would be so simple that users would want
to adapt it in their own, internal applications.

I also believe that one such tagging system could be developed based on the
EDIFACT concept of composite data elements. Every data element can be
uniquely identified according to the following formula:

TAGx_value_qualifier1_qualifier2.....

The Date/Time/Period segment (DTM) in EDIFACT is designed like that and ALL
data elements could be identified in the same way. (I know because I
designed an experimental EDIFACT transport message based on this concept
back in the early 90's - the message had only a fraction of the segments of
the standard EDIFACT message on which it was modelled)

The composite data element concept is important because it allows new data
elements to be introduced by adding new qualifier values without changing
the basic data/message structure.

EDIFACT, and X12, can become "simple" by designing a new set of segments
based on the above model and then construct messages that recognize that in
trade and transport the data structures in different messages are almost
identical, only the functions of the data structure changes as the data is
"moved". This function should be identified with a code, rather than a
whole new message.

This was recognized by the early trade facilitation efforts, when trade
document alignment were aligned so that a whole series of different trade
documents could be produced in a single typing using carbon paper.

I think that these observations are relevant for the ebXML efforts because
if the weaknesses and shortcomings of the edi standards are not properly
understood they may also not be improved upon - and the problem goes way
beyond human readability of tags and codes.

I am not very familiar with XML syntax and I don't know if is allows for
composite data elements - but I seriously hope it does, because if
so-called specific data elements must be used, thousands are required and
message structures will be inherently unstable.

If, on the other hand, composite data elements can be used with ebXML they
could possibly look something like this:

Data to be tagged: Estimated date of arrival July 14, 2000

EDIFACT tagging: DTM+132:20000714:102'

Possible ebXML tagging (?): DATE_20000714_EstimatedArrival_CCYYMMDD

Comments on the above would be most welcome.

Best regards,

Niels Rasmussen
(rasmus@netrover.com)







>Lisa
>
>To date I have been an avid reader, if not participant, in the ebXML list
>servers. However, your response below has made me speak what I have been
>thinking ever since the XML hype has started.
>
>You state:
>
>> This is where XML comes in.  XML has the technology and application
>vendors
>> attention.
>>
>> As for the really tough problems, semantically consistent, stable, and
>> concise messages, guidance for application vendors, consistent enveloping,
>> etc.  This is where ebXML comes in.  The context work being done in Core
>> Components will yield a solid technical approach to this difficult
>> problem.  In addition, when combined with process models, represents a
>> blueprint to application vendors for interaction with external systems.
>>
>
>>From what I am reading (in both the list servers and documents), I really
>cannot see how ebXML can solve any of the problems that EDI had. The
>semantics of the data being sent are the minor problem of any sender (or
>receiver) - the real problem is in the back end application being able to
>understand, process and correctly (i.e. as the sender requires) reply to the
>data received. In the real world, most senders and receivers are using
>different applications, requiring and providing different pieces of data to
>complete the required business process  - until everyone uses the exact same
>process model, I cannot see how these problems can be resolved by "YET
>ANOTHER STANDARD".
>
>As an EDI consultant, I have always found that the technology of sending and
>receiving message (whether they be UN/EDIFACT, X12, proprietary or even XML)
>has been the easy part - getting the business data suitable for both ends of
>the relationship has always taken the larger part of any implementation!! As
>an example, what if the receiving application requires their own product
>codes, delivery locations, whilst the sender has no way of converting these
>from their codes. Or worse, the sender produces invoices of what has been
>despatched at that time, while the receiver can only handle an invoice that
>contains details for a single purchase order.
>
>I will be the first to admit I am no XML expert - but to date, no one has
>been able to explain to me how XML (or ebXML) will solve these business
>issues, which are the real stopper for a SME that has a back end application
>(either in-house or package). Many that I have talked to as to why they want
>to use XML rather that "traditional-EDI" have stated that it is because of
>the lower costs of parsers (aka translators?) - but I am yet to be convinced
>that this is the 'real' cost of EDI - in my experience it has been the cost
>of implementing the messages into the back end application systems.
>
>Despite all of the above, I am keeping an open mind, and would like to hear
>comments to the contrary!
>
>Margaret Pemberton