Re: Concern with basic ebXML TRP Syntax/Semantics

[Jon Bosak <bosak@boethius.eng.sun.com>]

[Mark Crawford:]

| Thanks for your involvement in this.

Actually, that was a private note.  But since you've posted it, I
guess I'd better reply.

| IMHO this issue has arisen because of a very narrow focus of the
| TRP group on MIME as "the answer" with only passing attention to
| other (read XML) solutions.

A group that included some of the top SGML experts of the time
attacked the problem of how to package SGML documents five years
ago.  The conclusion of many participants, after months of very
difficult work, was: mime multipart/related.  The problem was that
multipart/related wasn't ready yet.  Now it is.  Having been
through that discussion already, I'm not excited about seeing
ebXML transport and packaging tied up for months coming to the
same conclusion.

I have seen the phrase "pure XML" bandied about.  Frankly, I don't
understand where the "pure XML position" is coming from.  I
started the XML effort in order to simplify "pure SGML" enough to
make it practical to use on the web.  XML is an exercise in
pragmatism.  If the easy and practical way to package XML is to
use mime multipart/related -- which would hardly be a big surprise
given the analysis this question received last time around -- then
it is very much in the spirit of XML to adopt that solution and
move on.

Is there something wrong with the mime solution?  If so, what?

If a mime system already deployed does work for this, why
reimplement a whole mechanism for transporting images and other
binary objects in the same package with XML documents?

|     I am very careful to explain to folks that in fact there is no
| XML "standard." Regardless, many people accept XML 1.0 and related
| W3C technical specifications as de facto standards.  I also
| believe that many folks believe that XML "standards" solutions
| should be constrained to the syntax rules contained in the W3C
| technical specifications.  Otherwise our good friends in the
| solutions development business will build proprietary,
| non-interoperable solutions that create a tower of Babel in the
| B2B space.

"W3C" and "a tower of Babel" are not the only options here.  To
me, a true standards process is a democratic process in which all
interested parties have a chance to participate.  By this
definition, ebXML is much closer to being a standards body than
W3C is.  

XML itself is based on a number of genuine international
standards.  None of those standards were defined by W3C; see
Appendix A of the XML Recommendation.  The XML 1.0 work took place
in W3C, but it does not depend in any way upon other work of the
W3C.

XML itself is just a subset of SGML, which is an ISO standard of
long standing, and of course the use of XML on the web relies on
IETF standards such as URLs and HTTP.  An open, international
ebXML solution managed by UN/CEFACT and OASIS and based on
standards from ISO and IETF is about as standard as standard gets.
I wouldn't worry about that part.

| (Yes I have read your article on the OASIS Process for Structured
| Information Standards and the use of Robert's Rules for OASIS
| Technical Committee's.  In your opinion does that apply to ebXML?)

I don't think so.  My understanding is that ebXML runs under
consensus rules inherited from UN/CEFACT.

| > The requirement to use only "W3C approved technical
| > specifications" is unnecessary and possibly harmful.  Can you
| > explain the reasoning behind this?
| 
|     See my previous comments on the reasoning.  Perhaps the
| wording is not clear.  As a member of the requirements project
| team, your help in rewording would be most appreciated.

I am not a member of the requirements group.  Other obligations
forced me to withdraw from that group shortly after its first
meeting in San Jose.  Sun is represented on the requirements group
by Turochas Fuad.

If it were up to me, I would merge a couple of the requirements
and simply say something like

   ebXML is based on international standards and is itself
   intended to become an international standard.

Jon