RE: COMPLEXITY BIG ISSUE

[David Burdett <david.burdett@commerceone.com>]

Michael

You make a good point about legacy systems and the need to "support" them. I
just find it difficult to imagine though that these legacy systems will
support the **complete** XML environment including parsers and schemas.
Therefore they will need to find some way of "interfacing" e.g. over a LAN,
to some more modern equipment that provides this environment.

I think therefore that the software library approach is the more likely.
However this doesn't mean that we can therefore make the spec arbitrarily
complex. We must still aim for simplicity for all the reasons you state.

David

-----Original Message-----
From: Michael Champion [mailto:mike.champion@softwareag-usa.com]
Sent: Monday, March 06, 2000 9:29 AM
To: [unknown]; [unknown]
Subject: Re: COMPLEXITY BIG ISSUE



----- Original Message -----
From: "David Burdett" <david.burdett@commerceone.com>
To: "David RR Webber" <Gnosis_@compuserve.com>; "Michael Champion"
<mike.champion@softwareag-usa.com>
Cc: "[unknown]" <ebXML-Transport@lists.oasis-open.org>; "[unknown]"
<ebXML-Architecture@lists.oasis-open.org>
Sent: Monday, March 06, 2000 2:12 AM
Subject: RE: COMPLEXITY BIG ISSUE
>
> Generally I agree, but for ebXML Transport, I think that once we get a
spec
> out, people like IBM, Sun, MS etc will quickly provide software libraries
> that make using ebXML style of messaging very easy. You will call an API
and
> it will generate the message in the correct format and manage its
(reliable)
> transmission to it's destination. For example how many people read the
HTTP
> spec in order to work out how to generate HTTP messages compared with
using
> a library of software they can use off the shelf?

In the early days of HTTP, LOTS of people read the spec and implemented it
themselves in whatever language was handy.  Its simplicity greatly assisted
its widespread adoption.  You have to *sell* ebXML in a competitive
environment, so making it easy for book writers, consultants, Perl hackers,
etc. to understand ebXML will promote its widespread adoption.

More to the point, there are a lot of legacy systems out there that will
need the developers to wire in ebXML support rather than getting it from a
systems vendor.  There are a lot of languages and systems out there in
widespread use, far more permutations than MS/Sun/IBM/etc. find it
profitable to support.  I seriously doubt if MS will support ebXML on 16-bit
Windows or DOS, nor Sun support it on Sun OS, etc.; but these systems are
still on the job out there, especially outside North America.  As I
understand the objectives of ebXML, you can't just leave these folks out in
the cold until somebody comes up with an easy to use API for an orphan
environment.