Re: XML vs. EDI questions

[jwells123 <jwells123@email.msn.com>]

Thanks very much, this definitely helps. My responses are interspersed.

> Most EDI software does come with mapping software, but....
>
> The real difficulty with implementing EDI *or* XML is getting the partners
> to understand what the various segment/elements (ANSI/EDIFACT EDI) or tag
> values (XML) mean "in the business context."  Take an example of segment
PO1
> of the ANSI 850 Purchase Order:
>
> PO1*00001*100*PC*2.62*CT*BP*12345~
>
> In element 6 and 7 ("BP" and "12345"), the item the purchaser wants is
> identified as "buyer's part number" ("BP") "12345."
>
> Gee that's great, but WHAT DOES THE BUYER USE FOR HIS PART NUMBER? If the
> seller does not know what that buyer's part number means, does he guess?
>
> Contrast (?) this with its XML counterpart:
>
> <buyerpartno> 12345 </buyerpartno>
>
> Hmmm, seems to me XML has really done nothing to resolve the *business*
> question.
>
> So a new message to be exchanged by partners needs the partners to agree
on
> what the meaning of the elements - or tags - means "in context."
>
> Sure, VANs can translate/map, for a fee, but if I have a VAN translate but
> how does the VAN know what to put in the target field specified by the
> seller (the VANs mapping customer)?

Thanks, that's a very interesting point. I don't know much about XLink, but
maybe the buyer part numbers could link to another document from the buyer
explaining to what their part numbers refer. Or, once the relationship
between buyer part numbers and seller part numbers is known, XSLT could be
used to map between them rather than hard-coding it into an application
somewhere.

I've also heard it's a common problem to have undocumented fields and no one
knows what they mean any more. Also, with no "authoritative"
standardization/repository of XML message formats, I can see people using a
lot of different tags for the same fields. Even with XSLT, people are still
going to have to spend time explaining the meanings of their tags to one
another.

All this would make it hard for the ad hoc, automated business relationships
we've heard proposed by B2B exchanges and MS with UDDI. I think there's a
business-related objection to those as well; companies might use a reverse
auction for their indirect goods (office supplies, etc) but they want
long-term relationships for their direct goods (the materials with which
they manufacture their products).

> This "translation" using XSLT is, in my view, more XML hype.

I think it depends. Suppose two companies use EDI and want to share data.
Each maps their application format to a different EDI format. So they create
a new mapping from their application format to an agreed-upon EDI format.

Alternatively, suppose they each map their application format to a different
XML format. So they create a new mapping between their different XML
formats.

Whether the second way is better depends on how hard it is for them to
create new mappings from their application formats to EDI formats. One
interesting XML article
(http://www.ontology.org/main/papers/glushko-xml99.html) suggests that this
usually requires tinkering with the application.

If lots of companies did not use separate EDI translators/mappers, but
actually altered their applications to make their output conform to EDI
standards, then I can see how this would happen. I don't know how long it
took between the appearance of EDI standards and the appearance of mapping
tools - but I do know that the packaged software industry was still in its
infancy in the 70s when the EDI standards came out....

> > 2. I've also read that connecting a company to a VAN is very
> > time-consuming and expensive. Is this generally true?
>
> No it is not.  It's fast and easy. (Well, it does require the prospective
> user to have already invested in technology:  something called a
> "telephone").  Expensive? Well, there have been any number of comparisons
of
> VAN pricing over the years, but since pricing has been somewhat volatile
of
> late, I'd pick up the phone and call around to get current prices. VAN
> service is essentially priced by the character, with subscriptions
available
> in which a fixed fee gets you so many characters per month, with an extra
> charge per character for going over. (Kind of like cell phone usage or
> automobile leasing).

Okay. I know VANs also provide a ton of services (store-and-forward,
transaction/rollback, non-repudiation) that you'd have to build on your own
with an XML/Internet system. I imagine VANs will begin providing these
services over the Internet to lower costs and be competitive, but the
Internet obviously isn't going to kill them.

> ANSI EDI also has a transaction set, the "868  Electronic Form Structure"
> designed for this purpose. I've seen a couple of these used by translator
> vendors to update customer systems for new standards tables, but in
> eighteen-plus years working with ANSI/EDIFACT EDI I've never seen it used
> between trading partners. (I work in manufacturing/distribution and
> healthcare; other industry segments may use this transaction set).
>
> XML DTD's (schema) serve the same purpose; but neither IMPDEF format or
868
> or DTDs address the underlying business questions.

True, and that's a point I intend to bring up - schemas will save you from
having to hard-code some of the really basic validation, but you've still
got to determine if a requested part number is valid, in stock, etc.