Re: Summary of XML Datatypes as required for B2B applications

["William J. Kammerer" <wkammerer@foresightcorp.com>]

To List Administrators:

This message was posted a week ago on Monday, never appearing on either
the ebXML Core Components or the XML/EDI Group mailing lists.  The ebXML
mailing lists periodically suffer from an outage which ultimately
results in empty messages from the ebXML owner being sent to everyone.
And the XML/EDI list almost always manages to lose messages, and I
expect this to be no exception.

To Ian Galbraith:

Using EDIFACT in an XML syntax, such as the DIN proposal, XEDI, or even
apparently EDML, would preserve EDIFACT's semantic content.  But why
even bother with the XML transformation step: just use EDIFACT (or X12
or HL7) as is, which is what I meant by "warts, delimiters, and all."
The ebXML Transport Packing framework will accommodate EDIFACT and X12,
and I would expect that ebXML be considered a great success even if the
only thing that came out of it was the TP&R framework;  it would
unequivocally identify the packages contained within, provide general
purpose routing, and in effect, give us the Grand Unified transport
framework (possibly obsoleting AS1, AS2, RosettaNet RNIF, Biztalk, etc.)

To Todd Boyle:

EDIFACT has a well-known subset, while if not "unambiguous," certainly
is easier to implement:  the EANCOM subset issued by the EAN used for
general trade and retail (roughly equivalent to the U.S. VICS subset of
X12).  Then there's SIMPL-EDI, which has a number of EDIFACT messages
which have really been whittled down to the bare essentials.  There are
innumerable other subsets, generally dealing with the needs of industry
groups.

   Right now the SMEs continue printing and mailing their checks
   and invoices, biding their time. The commercial companies are
   *miles ahead* of anything on this ebXML list.  Every day you
   waste, the commercial companies sign up 100,000 more people
   and their unit costs go down, and their rent-collecting models
   take firmer root.  For example, X.Com/PayPal has gone from
   zero to 1,000,000 users in the last 4 months.

Many commercial B2B companies are relying on their own proprietary
message formats, with the intention that the software at the other end
will also be of their making.   This is the reason vendor neutral
business-to-business interoperable standards are needed - so each
trading partner doesn't have to use a particular vendor's software or
web portal.

PayPal will probably follow the same proprietary model:  their
"locked-in" customers must use Paypal's conventions to pay sellers for
Beanie Babies (through eBay).  PayPal might even have little interest in
devising a general format (XML or otherwise) where other companies could
muscle in on their consumer to consumer payment business, which I don't
think EDI ever pretended to address.

And I would be almost positive that PayPal is using stinky old EDI (most
likely X12 820s in the U.S. and Canada,  EDIFACT PAYMULs elsewhere) - or
ACH - to effect the bank transfers.  This gives PayPal relative freedom
to move from one VAB (Value Added Bank) to another, using interoperable
X12 standards.  And this is also a classic example of EDI being
"shrink-wrapped" into a product (or ASP, in the case of PayPal).

William J. Kammerer
FORESIGHT Corp.
4950 Blazer Memorial Pkwy.
Dublin, OH USA 43017-3305
(614) 791-1600

Visit FORESIGHT Corp. at http://www.foresightcorp.com/
"Commerce for a New World"