OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


----- Original Message -----
From: "Dave Hollander" <dmh@commerce.net>
To: "David RR Webber" <Gnosis_@compuserve.com>; "Michael Champion"
<mike.champion@softwareag-usa.com>; "Dave Hollander" <dmh@commerce.net>
Cc: "[unknown]" <ebXML-Architecture@lists.oasis-open.org>; "[unknown]"
Sent: Sunday, March 05, 2000 1:38 PM

> Light weight is a matter of opinion and perspective. Compared to
> today's backoffice infrastructures, we can do a lot and still be
> considered "lightweight".


> As commercial implementations emerge we will see about the other
> claims of expense and specialized knowledge. IBM, Microsoft,
> CommerceOne and Extensibility have implemented major portions of
> the spec and do not express undue concerns about supporting it.


> I know at least three DTD authors whose DTD skills I respect very
> much that have begun porting to XML Schemas. They are excited and
> pleased with the results. As the industry starts creating tools
> and books, the skills issue should recede

Forgive me if I'm preaching to the choir, but this issue hits one of my hot
buttons.  These quotes from Dave Hollander's post are reasonable and
obviously well-informed.  In the long run, I suspect that something much
like XML Schema will be the basis for much of what we do to agree on the
format of e-business communications.  Nevertheless, a few points need to be

- Time to market: ebXML has a lot riding on it, so getting the spec written,
adopted, and widely implemented QUICKLY is paramount.  In my experience,
this will require a vigorous application of the 80:20 rule, Occam's Razor,
etc.  Whether ebXML systems are "lighter" than existing back office systems
is of little relevance if ebXML's window of opportunity is missed.

- Software Reliability: Much of the world economy may soon depend on ebXML;
presumably giants like MS and IBM, and experts like CommerceOne and
Extensibility will be able to develop quality implementations of any
feasible spec.  But think about all the *other* people out there
implementing ebXML-based software! The ease of developing fast, reliable
implementations will degrade exponentially as the complexity of the spec
increases.  If the designers of ebXML do not find a good 80:20 point, then
many consumers of the spec will be forced to do so ad hoc, with unpleasant
implications for interoperability, or quality will suffer, with unpleasant
implications for the reliability of e-business. In the long run the market
will sort this all out and "bad" implementations will go away (one way or
the other) ... but "in the long run we are all dead".

- Target Audience: ebXML should be targeted to the ordinary business
programmers of the world, not "people whose DTD skills [an XML expert]
respects very much" if it is to succeed in the marketplace.   Ponder the
success of HTML, Visual Basic, XML itself, etc.: all these can be used
effectively by virtually anyone who is computer-literate.  Contrast this
with the non-success of SGML, LISP, etc.: technically superior but difficult
for the ordinary person to use quickly and effectively.

These arguments apply to XML Schema as well as to ebXML; I personally hope
that the W3C refocusses that effort on finding the 80:20 point (for the
e-business world) NOW and achieving the rest of Schema's lofty goals in the
next release.  Assuming that they do not, ebXML would be well advised to
find such a point themselves, or to use a simpler schema language (and let
people use XML Authority or whatever to translate to the W3C spec when

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC