RE: Summary of XML Datatypes as required for B2B applications

["Todd Boyle" <tboyle@rosehill.net>]

EDI users often wax poetic about EDI.  But small business simply cannot
afford transaction connectivity having any component of labor cost.

Ian, you said "conversion of EDIFACT dictionaries" would not be difficult;
please provide a definitive example, into an XML DTD or schema that would
be useful for small business, in the exchange of business messages.

EDI requires human negotiation and setup, causing costs for users, and
revenues for EDI vendors.  Does EDI have a suitable unambiguous subset?
Does EDIFACT provide definitions of semantic meanings or business process?
Does EDIFACT imply any consistent data model, cleansed of overlapping
synonyms, duplicated structures, and collisions?

Small business has no choice but to wait, and do NOTHING, until transaction
cost of ecommerce comes way down.  That might happen via XML if an unambiguous
vocabulary emerges from ebXML.  Or, it might happen within various commercial
portals, Microsoft, Checkfree, AOL, etc.  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,

Respectfully,
Todd Boyle

Ian Galbraith said Sunday, April 16, 2000 8:34 AM on the ebXML Core Components
list, and XML/EDI Group Re: Summary of XML Datatypes as required for B2B
applications

> Oh William, how right you are!  The EDIFACT dictionaries (and the rest) have
> evolved through years of consideration of real user needs; it is not a big
> deal to convert the essential semantic content of these dictionaries into a
> different syntactic environment.  This was exactly the intent behind EDML.
> The EDML proof of concept work demonstrated a means of transferring semantic
> content (ie data dictionaries) developed for one syntactic message structure
> into a quite different syntactic structure.  So to my mind an obvious way to
> accelerate the development of XML-based ecommerce would be to exploit the
> EDIFACT (and other) data dictionaries. But right now I don't have much
> confidence that the good bits of EDIFACT, X12, HL7, etc will actually be
> exploited.  It seems perhaps, that in rejecting the syntactic structures of
> "traditional" EDI the semantic baby is being thrown out with the bathwater.
>
> Best regards
>
> Ian
>
> -----Original Message-----
> From: William J. Kammerer <wkammerer@foresightcorp.com>
> To: 'ebXML Core Components (E-mail)' <ebxml-core@lists.oasis-open.org>
> Cc: XML/EDI Group (E-mail) <xmledi-list@lists.bizserve.com>
> Date: 15 April 2000 15:12
> Subject: Summary of XML Datatypes as required for B2B applications
>
>
> >There's an interesting thread entitled "Summary of XML Datatypes as
> >required for B2B applications," started by Martin Bryan, with commentary
> >by Messrs. Kotok, Folkerts, and Haugen, on the XML-EDI mailing list. See
> >http://www.mail-archive.com/xmledi-list%40lists.bizserve.com/ for the
> >archives.
> >
> >Note that EDIFACT is being re-invented all over again, especially the
> >MEA, CUX and DTM segments. Bob Haugen says:
> >
> >   I think all of your other suggestions are essential to business
> >   communications.  One thought:  if you left the timestamp off
> >   the currency and put it on the business event (which needs it
> >   anyway), then your measurements and currencies
> >   would have the same structure ( amount and unit).  This could
> >   mean one structure for measurements of all resources.
> >
> >Absolutely brilliant!  Can't argue with this - building up semantic
> >meaning from lego blocks.  EDIFACT does this already with the standard
> >CUX (Currencies) - DTM (Date/time/period) segment group.  X12 does also,
> >to some extent, but tends to overload its segments semantically (e.g.,
> >the X12 CUR segment includes the date and time itself, and does not
> >rely on a separate segment to convey the exchange period).
> >
> >EDIFACT has been around for over a decade, and apparently is too complex
> >to use (because of the semantic building block concept?).  Otherwise we
> >wouldn't be all scrounging around trying to reincarnate EDI in XML
> >syntax.
> >
> >But I do like the concept of semantic building blocks or core
> >components.  So why re-invent them from scratch?  Just take a look at
> >the EDIFACT directories and dictionaries, and all of the core components
> >for ebXML can be effortlessly extracted.
> >
> >Or, why don't we just use EDIFACT for ebXML: warts, delimiters, and all,
> >and save ourselves a heck of a lot of time and trouble?

Because that wouldn't save non-EDI users any time or trouble, and there are
hundreds of millions of non-EDI consumers and small businesses in the
developed countries who need to conduct business over the internet.

EDI has had its chance but the numeric codes and secret terms like
MEA, CUX and DTM are never going to make it.  Rescue yourself before
all of EDI goes down the tubes: Spin off a subset that is more acceptable
to the broader public.  That's what SGML did.  Look what happend to
X.500.

The whole wide internet has such a *hopelessly* large range of users that
the perimeter of common vocabulary is going to be smaller.  There is a
mathematical law at work, like when you draw 1,000 circles on a venn
diagram.  You are not going to satisfy a large percentage of the needs
of all users, like you did with EDI.  With EDI you would create another
100 elements and satisfy in another 5% of the needs.  This is a different
game with a long tail: once you get up around 500 elements, you only get
another 1% of the needs from another 100 elements so it's hardly worth
the trouble.  Accordingly the game is less fun but it is a lot easier:
just identify 300 or 400 core elements, and quit.

The form of the new XML could be very simple and obvious.  It would need
to provide for extensibility but the core vocabulary is something you could
launch in 30 days out of the common denominators between EDIFACT and
the existing XML vocabularies.

TOdd Boyle CPA  Kirkland WA

> >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"
>