Ken Steel, of ICARIS Services in Amsterdam, Melbourne, and Silicon
Valley, asked some very pointed and salient questions re: XML and its
applicability to B2B interoperability.
I do agree with Ken that it shouldn't be up to him to have to look up
the ebXML specifications, as suggested by Alan Kotok, in order to help
the proponents of ebXML justify it in relation to EDI. It's the
responsibility of the ebXML'ers to justify ebXML, or at least whet the
prospect's appetite enough to warrant further investigation. And
besides, I would never point someone to the ebXML specifications, only a
few of which actually exist. The drafts are, by and large, unreadable
at this stage. And many of them contain page after page of UML
diagrams, which would scare any sane person away.
But perhaps I might augment some of the answers provided by Alan and
Rachel Foerster:
"What problems (and costs) that stop the wider adoption of EDI are
solved by using XML?"
Hardly any. You could argue, though, that using a common syntax that
*everyone* understands eliminates perhaps 5% of the angst involved in
using EDI. For example, XML already elegantly takes care of various
character encodings and repertoires, avoiding the weird contortions you
have to go through with EDIFACT (special codings in the UNB specifying
the UNOY syntax level and additional qualifiers). Just look at the
questions people have posed on EDI-L re: delimiters in EDIFACT and X12;
much of this is not an issue in XML because of the explicit tagging and
the otherwise very precise rules in the XML specification for escape
sequences when encoding special characters.
Other adhoc measures, common in X12 and EDIFACT, to resolve segment
collision are alleviated because XML gracefully provides (element)
nesting, whereas in EDI message designers have to carefully eliminate
ambiguity in the segment structure by repetition counts and usage
requirements.
When all is said and done, though, it's hard to believe that these minor
syntax considerations are what hold back greater acceptance and use of
EDI.
"How does XML achieve these dramatic improvements over EDI so that XML
brings automated B2B interoperation within the scope of the resources of
small 20-employee organisations?"
XML doesn't, by itself. As Rachel Foerster noted, XML has the
mindshare, which translates into ubiquitous infrastructure support.
There *will* be standard ways of moving XML and attachments from point
to point in a secure manner, using ebXML's Messaging Services. At the
very least, because of ebXML's MS reliance on MIME encapsulation of
payloads, any mail client will be able to send and receive ebXML
messages as ordinary e-mail. Attachments in formats alien to EDI, such
as JPEGs and PDF documents, are handled consistent with e-mail in that
you can simply point and click on the attachment icons. Compare that
with X12 EDI, where the EFI and BIN segments would have to be processed
without the help of a MIME decoder that "knows" what to do with
attachments.
All this means that a cottage industry of applications can be developed
based on ebXML standards, which would provide the shrink-wrapped
software that the small 20-employee organizations would use. ebXML will
make it easier for software developers to use common interoperable B2B
standards supported within their applications; there is no intention
that SMEs would hunker down and *do* ebXML themselves.
"More particularly, how does XML avoid the problem of upfront discussion
between the parties defining the interchange structure and then
customising the implementation for each pair of trading partners?"
XML doesn't.. But ebXML, as Alan Kotok alluded to, includes support for
(some) automation of the TPA using Trading Partner Agreement Markup
Language (tpaML); see http://www.oasis-open.org/cover/tpa.html.
"The problems are different, but XML uses tags to identify data. Doesn't
that cause a different set of big problems: A language must be selected
for the tag. Doesn't that preclude XML from being used in a multilingual
environment?"
The XML element tags may be in a particular language; this is not
unlike programming, where most variable names are in English, even
though the application is used in a multilingual environment. If XML
documents are examined by a human at all, it will probably be done by a
programmer.
The data that is carried between the tags could very well be in any
language or character set, though coded identifiers (e.g., ISO country
codes or EAN product IDs) would still be preferred by applications.
And for sure, ebXML element tags will most likely be written in
English - the language of Longfellow, Churchill, Shakespeare, Mencken,
Jesus and Jefferson. But preferably the hardy American variety ripe
with republican virtue as opposed to the effete version used across the
sea.
"Doesn't prior discussion need to take place between the parties and the
implementation need to be customised for different tag names used to
identify the same data in the different XML (DTD) implementations of
each [trading] partner?"
You already asked this.
"Doesn't the receiving party have to cope with different tagging names
and the burgeoning differences continuing to emerge in the way the data
semantics are represented and tagged in the XML programming language?
Does the small user have to learn to program in XML or call in
high-priced consultants to implement each trading partner?"
If ebXML is successful in providing an XML framework for developing B2B
standards, then the tag names should be consistent within the same
problem domain when used for the same purpose. As said above, the small
user will be insulated from ebXML standards by the use of off-the-shelf
software.
"How can the small end user customise the implementation for all these
differences in tagging and semantic representations for each trading
partner and the use of XML still fit within the available resources of
the smaller organisations?"
If all the trading partners are using the same interoperable standards
(in this case, ebXML), customization should be simplified and
implementable in off-the-shelf software.
"How is the small user able to get its application software package
customised for each of the DTDs and tagging/semantic structures demanded
by each of the larger trading partners?"
Customization would supposedly be driven by the registry/repository,
which could be queried for the specific configuration of core components
used by the other trading partner. Since the RegRep specification uses
UML diagrams, I haven't made it past the first page, so I can't tell you
how this will be done.
"How does an existing EDI user implement XML without having to double up
on the overhead and running costs (translators, training, reprogramming
applications to select the EDI or XML stream depending on the trading
partner, cope with two different sets of operating problems and
complexities etc)?"
ebXML Messaging Services supports EDI (X12 and EDIFACT) messages as just
another payload. Right off the bat, you'll be able to exchange EDI
point to point, bypassing the VAN. Or you can continue to use a VAN,
since VANs will probably support ebXML messaging services.
Even if XML documents are exchanged, mapping to and from your internal
applications files will still be required, though the task will be
somewhat simplified because the templates for business messages will be
automatically retrieved from the ebXML registry/repository. Someday pigs
will fly too.
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"
=======================================================================
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
