RE: Summary of XML Datatypes as required for B2B applications

[James Whittle <james.whittle@e-centre.org.uk>]

After reading this string of mail I have to make a brief comment. Are you
all aware of the massive amounts of resource that go into implementing
UN/EDIFACT and maintaining it even in a small tading community? Todd is
correct that UN/EDIFACT is just not accessible enough for SMEs.

I have to frank and say that if the solution to the worlds XML b2b problems
were simply about translating UN/EDIFACT "warts and all" into XML do you not
think the worlds software vendors would not have done so already? Lets not
miss a trick here, I agree that we do not want to throw "the baby out with
the bath water" but lets make sure we lever maximum advantage from XML as a
syntax and please, please lets make implementation a more simple, standard
and cost effective process of all.

Kind regards

James Whittle
Executive

Tel. No. 44 (0)20 7655 9022
Fax No. 44 (0)20 7681 2278


10 Maltravers Street, LONDON, WC2R 3BX.
www Address: www.e-centre.org.uk <http://www.e-centre.org.uk>  
e-mail james.whittle@e-centre.org.uk <mailto:james.whittle@e-centre.org.uk> 


Best business practice in a digital age.

Important Notice 

The above information is intended only for the person(s) or entity to which
it is addressed, and may contain confidential or privileged material. Any
use (including retransmission or copying) of this information by person(s)
or entity other than the intended recipient is STRICTLY PROHIBITED. If you
are not the intended recipient of this transmission, please would you
contact the sender and delete the material from any computer. The sender is
not responsible for the completeness or 
accuracy of this communication as it has been transmitted over a public
network.


		-----Original Message-----
		From:	Todd Boyle [mailto:tboyle@rosehill.net]
		Sent:	17 April 2000 06:43
		To:	Ian Galbraith; 'ebXML Core Components (E-mail)';
William J. Kammerer
		Cc:	David; XML/EDI Group (E-mail)
		Subject:	RE: Summary of XML Datatypes as required for
B2B applications 

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