Re[3]: Concern with basic ebXML TRP Syntax/Semantics

["Mark CRAWFORD"<mcrawfor@lmi.org>]

Jon,

    Thanks for your involvement in this.  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.  My concern has always been to ensure
that TRP is not simply repackaging solutions that were developed elsewhere by
members of that project team, or that they are not simply looking for new ways
to repackage and sell traditional EDI, but that they are looking at all
alternatives with special emphasis on XML solutions.    

    FYI - My original message to Chris stated -

        "I think we will have to agree to disagree.  My argument all along has
been that we are about XML, not using the guise of ebXML for individuals to
resurrect their pet technology standards projects of the last several years.
(and I am not just talking about TRP, but some of the other efforts within ebXML
as well).

"If webMethods can exchange information using XML wrappers, and if BizTalk can
exchange information using XML wrappers (yes I know they use mime to encapsulate
binary objects within the XML document instance), then why can't we? And oh by
the way, if MIME is the answer and simple e-mail attachments are the best
solution, explain to me how come people still have serious email and attachment
interoperability problems? Also, if we are going to use MIME as the only ebXML
solution, which MIME RFC are we going to use?"
  

 I think that if you look at the discussions on the TRP listserve you will see
that there are some within that project team who believe that MIME is not
necessary in most cases and that the team should be supporting an XML
alternative.  Unfortunately they are in the minority and some may feel they have
not been given credence (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?) 

FYI I ended my original message to Chris as follows - 

    "If TRP believes that XML technology does not support all of the
requirements for interchange they have addressed, then I believe this is an
issue for the entire ebXML plenary not just TRP.  There are a number of
alternatives open -

    1) Provide XML solutions for those requirements that can be
addressed(reduce requirements)
    2) Provide dual path XML and MIME solutions
    3) Provide a MIME solution and publically state that we are not developing
XML based solutions, but another MIME standard for exchanging XML content
because the technology is too immature to support B2B data exchanges."

My preferred solution would be number 2, followed by number 1, then number 3 as
a last resort.  However if the technical experts in TRP really believe that they
can not provide an XML solution, then we (ebXML) should publicly state that XML
does not support all facets of B2B interoperability.

WRT your questions, specific answers follow -

>1. The W3C has no solution for XML packaging and does not have the  >resources
to pursue a solution at the present time.

    Understand. If the W3C had solutions for everything we wouldn't need to be
here.  It is important to note we have not said that ebXML solutions must be W3C
specifications - only that they should be based on those specifications.  IMHO
this is not restrictive because it allows us to develop solutions that meet our
business needs while only requiring that we adhere to XML 1.0 and related
technical specifications in developing those solutions.  Thus, if we develop an
XML syntax based packaging solution, we are in compliance with the requirements
document.  By the same token, if we develop a MIME based packaging solution as
an alternative to the XML solution, we are also in compliance with the
requirements document. I know the TRP folks have stated they will use existing
solutions whereever possible.  However I also believe that we have 12 months
left in ebXML to try and develop and XML solution.  If we can't get it done -
fine.  But if we don't even try - shame on us.

>2. The closest thing to an XML packaging spec is the SO Catalog developed >by
OASIS.  Not W3C.

    Have the TRP folks looked at this?  What about SOAP?  What about the BizTalk
solution? What about others in the XML space that may be under development?    

>3. The W3C is not, in fact, a standards body; it is a research project of >MIT.
 XML is a profile of an ISO standard, ISO 8879.

    I understand this.  I also understand the differences. I also understand the
W3C's position on their specification and its relationship with ISO.  I am sure
you are not suggesting that XML is an ISO standard, although there are many that
hold that it is. 

    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. 

>4. ebXML messaging will of necessity use a number of standards that have
>nothing to do with W3C -- Unicode, for example.

    See section 2.3 of the requirements document.  If there are others, please
share them with us so we can include them in the requirements document.

>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.   

    
Mark
Mark Crawford
Research Fellow
______
LMI Logistics Management Institute
2000 Corporate Ridge, McLean, VA 22102-7805
(703) 917-7177   Fax (703) 917-7518
mcrawfor@lmi.org
http://www.lmi.org
"Opportunity is what you make of it"



____________________Reply Separator____________________
Subject:    Re[2]: Concern with basic ebXML TRP Syntax/Semantics  
Author: Jon Bosak <bosak@boethius.eng.sun.com>
Date:       4/10/00 10:53 PM

Mark,

Chris Ferris has brought the following passage to my attention:

| The Transport/Routing and Packaging Project Team detailed
| requirements and deliverables will:
| 
|  - Use W3C approved technical specifications as the basis for all
|    solutions
| 
|  - Develop alternative solutions using other technical
|    specifications such as those of the IETF where they add value

This concerns me for several reasons.

1. The W3C has no solution for XML packaging and does not have the
   resources to pursue a solution at the present time.

2. The closest thing to an XML packaging spec is the SO Catalog
   developed by OASIS.  Not W3C.

3. The W3C is not, in fact, a standards body; it is a research
   project of MIT.  XML is a profile of an ISO standard, ISO 8879.

4. ebXML messaging will of necessity use a number of standards
   that have nothing to do with W3C -- Unicode, for example.

The requirement to use only "W3C approved technical
specifications" is unnecessary and possibly harmful.  Can you
explain the reasoning behind this?
    

Jon