There is a comment on this at slashdot
(http://slashdot.org/article.pl?sid=00/12/13/1431233&mode=thread)
Interesting that the columnist cites a source well known to be more than a
little MS friendly, using words like 'lame.' An indication of how the mood
of this discussion runs in the general public, as well as on this list.
The /. threads are also interesting.
Michael J. Cannon
-----Original Message-----
From: Electronic Data Interchange Issues
[mailto:[EMAIL PROTECTED]]On Behalf Of Alan Kotok
Sent: Wednesday, December 13, 2000 4:38 PM
To: [EMAIL PROTECTED]
Subject: Re: ebXML Passes Critical Interoperability Milestone
Ken, et al.
Let me try to answer your questions as best I can. You will forgive my not
providing a point-by-point response. I highly recommend you visit the
ebXML Web site that has draft specifications open to anyone. But let me
make a few points which I believe addresses the theme of your questions ...
The ebXML initiative has a number of features that build on the EDI
experience but make it more accessible to smaller companies. One of those
features is the electronic trading partner agreement or TPA. As you note
TPAs as they now exist require a lot of up-front work. Electronic TPAs
will reduce that workload significantly. Again, I suggest you visit the
ebXML Web site for details or come to our conference in March that has a
session devoted to electronic TPAs.
An important feature of ebXML is the use of registries and repositories
that store the industry business processes, message formats, and
vocabularies. Business processes are stored as metamodels that generate
the basic message formats and data. The vocabularies will include
industry-specific terms (the word 'signature' in printing means something
very different from the same use of the word in finance) as well as terms
that are used across industries. These latter terms are called core
components in ebXML-ese and they add significantly to achieving
interoperability. With much of the functionality stored in the registries
and repositories, the end-user software can be smaller and less expensive.
One of the goals of the ebXML initiative is to ease the transition from
EDI. The core components team plans to express these items in a neutral
syntax so they can be mapped to their equivalents in current EDI
transactions and messages. In fact, X12 plans to start developing
accredited cross-industry XML standards, working with the business process
models and core components in ebXML (and coordinate this work with the
UN/EDIFACT Work Group). If you don't mind reading another press release,
see:
http://www.oasis-open.org/cover/ascX12-disa.html .
Your questions represent the very issues that ebXML is addressing. The
specifications are there for anyone to read or comment on. As mentioned
in my earlier message, ebXML is still a work in progress, but it is taking
shape quickly. Best regards.
Alan Kotok
Director, Education and Information Resources
Data Interchange Standards Association
[EMAIL PROTECTED]
+1 703-518-4174
** DISA's E-Business and Internet Conference, 7-9 March 2001, in San
Francisco.
http://www.disa.org/conference/annual_conf/index.htm **
At 07:10 AM 12/14/00 +1100, Ken Steel wrote:
>Alan Kotok wrote:
> > In the U.S., the median size of printing companies is 20
> > employees. Only the largest printers of magazines and catalogs can
afford
> > to use traditional EDI. Something like ebXML offers these small
companies
> > the opportunity to benefit from business data exchange, where before it
was
> > well beyond their resources.
>
>Alan,
>
>Thanks for a more detailed answer.
>
>What problems (and costs) that stop the wider adoption of EDI are solved
>by using XML?
>
>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?
>
>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?
>
>The problems are different, but XML uses tags to identify data. Doesn't
>that cause a different set of big problems:
>
>1. A language must be selected for the tag. Doesn't that preclude XML
>from being used in a multilingual environment?
>
>2. 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 trding partner?
>
>3. 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?
>
>4. 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?
>
>5. 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?
>
>6. 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)?
>
>
>Regards,
>Ken
>--
>Ken Steel
>ICARIS Services Amsterdam, Melbourne, Silicon Valley
>Research results: http://www.icaris.net/
>Email: [EMAIL PROTECTED];
[EMAIL PROTECTED]
>
>=======================================================================
>To contact the list owner: mailto:[EMAIL PROTECTED]
>Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
=======================================================================
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
=======================================================================
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
