Sorry,
Here's a cleaned up version of my comments.
Rachel
I've inserted the full quote below so that the individual making the
comment is identified. I do take issue with Mr. Zachmann's assertion
that ebXML is just Sun and a bunch of bureaucrats. Major participation
is also by IBM, Commerce One, Cisco, Intel, OMG, Sterling Commerce,
WebMethods, etc. Now, I will agree with Ken's observation that these
are vendors....but the hope/expectation is that the vendors and ISV's
will incorporate the ebXML specification into their product offerings.
So, I would be more than a bit concerned if the vendors were NOT
participating in a big way.
On the other hand, I've read MS' Biztalk documents and I do agree that
their concept appears to be much more complete and coherent than
others. But that doesn't mean that other concepts/approaches should
not see the light of day....why should anyone abdicate the whole space
to MS? Let them earn it, the old fashioned way, by delivering products
that satisfy needs/solve problems!
<quote>
"I think they (Microsoft) will have real traction with this product,"
said Meta Group vice president Will Zachmann. "Microsoft's story on
this (XML) front is much more coherent than any other companies have
to offer. ...The only real alternative to BizTalk is, ebXML and it's
lame. It's just Sun and a bunch of bureaucrats backing it.
</quote>
Rachel
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/
=======================================================================
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
