Re: Concern with basic ebXML TRP Syntax/Semantics

[Christopher Ferris <chris.ferris@east.sun.com>]

Mark,

Please see below.

Cheers,

Chris
Mark CRAWFORD wrote:

> 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

This characterization is quite inaccurate and uninformed. We are, and
have been, quite willing, as Rik and Dick have previously stated, to
consider an XML based approach to packaging. We researched the
matter and could not come up with an appropriate solution. When one
does become available, and has been passed through the W3C (or
other) process to become a "standard" or recommendation, then
we will reconsider the TR&P packaging specification.

Our intent has been, and continues to be, to submit our reqirements
to W3C or whichever body chooses to engage in the specification of an
XML packaging solution, which IMHO is clearly needed. We felt
that it was inapproprate for us (TR&P WG) to define the specification
ourselves.

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

We are not. Yet we are also quite mindfull of what I consider to be
even more important requirements, that we not reinvent the wheel
and that we leverage existing solutions as well as provide for migration
from existing EDI and developing XML standards such as RosettaNet,
EDI/INT, etc.

Our use of MIME is trivial, as it merely forms the saran-wrap for
compound documents (header and payload(s)). Once stripped of
the MIME MULTIPART/RELATED wrapper, you're left with
XML. MIME is NOT used for expression of the header elements
themselves.

>
>
>     FYI - My original message to Chris stated -

<snip/>

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

which is effectively exclusive by its very nature. ebXML should be
inclusive in its requirements, providing for a path which all may
follow.

>
>     2) Provide dual path XML and MIME solutions

This will only lead to fragmentation of the "standard", with some
chosing to implement one and not the other, which effectively
defeats the original purpose of ebXML. We discussed this at length
and felt that it was better to arrive at a single approach for all messages,
leaving nothing to the imagination and ensuring compatiblity of
implementations.

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

Oh come on! Ths is so far from the mark it isn't funny. We are not developing
a MIME standard, we're leveraging a very small subset (multipart/related)
which is already widely supported.

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

To what purpose? Are we here to prove that XML can do all?
TCP/IP is not based on XML, and yet it is fundamental to its
operation. HTTP, SMTP and other transports aren't based on
XML, although they can (and will) be leveraged to transport
XML documents relevant to B2B intercourse.

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

I disagree! We don't have 12 months, we need something in the TR&P
space yesterday so that we won't be faced with a cacophony of incompatible
vertical standards which have developed/adopted incompatible TR&P
solutions! The sooner we can arrive at a specification for the TR&P the
better, IMHO.

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

No, we haven't considered SO Catalog. I will certainly look into this
further. As for SOAP, I don't see how it applies. SOAP is an RPC specification,
not a messaging or packaging specification. We repeatedly asked
Microsoft for information on the BizTalk approach (which is not publicly
posted at present) and heard nothing in response. Note also that
neither SOAP nor BizTalk are based on W3C recommendations.
Both use XDR not XML Schema (which itself hasn't yet garnered
W3C recommendation status).

As for "others" in the XML space, what others?

<snip/>