[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: COMPLEXITY BIG ISSUE
----- 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]" <ebXML-Transport@lists.oasis-open.org> Sent: Sunday, March 05, 2000 1:38 PM Subject: Re: COMPLEXITY BIG ISSUE > 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". [snip] > 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. > [snip] > 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 considered: - 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 necessary).
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC