RE: Concern with basic ebXML TRP Syntax/Semantics

["Rik Drummond" <drummond@onramp.net>]

When Dick writes the packaging document, he will say that xml will not
handle our needs at the moment, but as it matures in this area we will shift
to a totally xml package.

Lets don't get caught in an "when one has a hammer, every thing is a nail"
issue.

xml will not solve all problems, especially at its current stage of
development.

-----Original Message-----
From: owner-ebxml-transport@lists.oasis-open.org
[mailto:owner-ebxml-transport@lists.oasis-open.org]On Behalf Of Dick
Brooks
Sent: Friday, April 07, 2000 9:07 AM
To: Kit (Christopher) Lueder; Christopher Ferris
Cc: ebXML-Transport@lists.oasis-open.org; ebxml-requirements
Subject: RE: Concern with basic ebXML TRP Syntax/Semantics


Rik,

This looks like an issue for the TR&P chairman to resolve. You lucky guy!

Dick Brooks
http://www.8760.com/


-----Original Message-----
From: owner-ebxml-transport@lists.oasis-open.org
[mailto:owner-ebxml-transport@lists.oasis-open.org]On Behalf Of Kit
(Christopher) Lueder
Sent: Thursday, April 06, 2000 4:44 PM
To: Christopher Ferris
Cc: ebXML-Transport@lists.oasis-open.org; ebxml-requirements
Subject: Re: Concern with basic ebXML TRP Syntax/Semantics


Thanks, but you need to take this back to the ebXML requirements group,
for alignment. I am cc'ing them on this.
Kit.

Christopher Ferris wrote:
>
> Kit,
>
> While I wasn't able to participate the the f2f meeting in
> Dallas and can't speak to the finalized packaging minutia
> I can address this from the perspective of one of the
> members of the packaging sub-team.
>
> We discussed this in depth in the packaging sub-team.
> We felt that there was inadequate support in the various
> W3C XML recommendations to support our requirements
> which follow:
>
> - Able to handle large documents
> - Able to envelope any document type
> - Minimize intrusion to payload (special encodings or alterations)
> - Minimize potential for abnormal termination caused by envelopes
> - Facilitate a migration path for existing installed base and technologies
> - Low processing overhead
> - Support for recursive documents
> - Able to preserve digital signatures
> - Able to unambiguously identify signed data
>
> To quote Dick's minutes of our sub-team meeting:
>
> <db>
> Both MIME and XML were discussed relative to these requirements. It
> was the groups consensus that MIME was better positioned today to
> meet the stated requirements. However, it was also believed that XML
> would mature as a packaging technology and the ebXML group should
> continue to monitor XML's progress for possible inclusion at a later date.
> It was also believed that Microsoft may have addressed some of the
> issues affecting XML's packaging ability. Dick Brooks accepted an
> action item to contact Microsoft to request information describing
> BizTalk's packaging functions to see if this may provide an XML
> packaging solution that meets the above requirements.
> </db>
>
> Another consideration in our work, and something clearly called out
> in the ebXML requirements document are the vision bullets. Specifically:
>     - is fully compliant with W3C XML technical specifications holding a
>         recommended status
>     - maximizes interoperability and efficiency while providing a
>         transition path from accredited electronic data interchange (EDI)
>         and developing XML business standards
>
> The first is key. It refers to W3C technical specifications holding
> a *recommended* status. The second is also key. It refers to
> a requirement to enable existing solutions such as RosettaNet and
> EDI/INT, etc. to interoperate (at least that's how I read it).
> This second bullet is called out again in the "General ebXML
> Principles" section in the Requirements document. Someone certainly
> thinks it s important. I for one concur.
>
> Another consideration which went into our thinking is the availability
> of software to handle the package. HTTP and SMTP clients and
> servers already support MIME and are both inexpensive and
> widely available if not ubiquitous.
>
> In the Requirements document, under the TR&P sub-section, #2
>     "Leveraging existing technology encompasses both the ability to
>     interoperate with existing technology as well as the ability to
>     migrate to the new technology".
>
> In fact, that whole section pretty much sums it up for me.
>
> I believe that there is consensus that ultimately, we will transition
> to an XML-based approach to packaging, but at least for the
> first go, MIME is the only solution which satisfies all of the
> requirements.
>
> To my knowledge, the ebXML Requirements document doesn't
> say "use XML to the exclusion of any other technology just because".
> MIME seems to meet our requirements and since the content
> of the MIME segments is XML (except in cases where an
> "attachment" is of some other type such as image, etc.) we're
> also meeting the spirit of the ebXML requirements.
>
> If you have knowledge of a purely XML-based packaging
> solution which meets all of the stated requirements, and which
> the packaging sub team has missed in its considerations, I'm
> sure that we'd be glad to reconsider.
>
> Cheers,
>
> Chris
>
> "Kit (Christopher) Lueder" wrote:
>
> > I have a concern with the basic ebXML TRP approach. As I indicated last
> > month, as far as I know, the TRP approach is in conflict with the ebXML
> > Requirements specification. If I understand right, the ebXML TRP
> > solution is MIME based only, which is not an XML solution.
> >
> > I quote the last paragraph from Section 1 Introduction of the ebXML
> > Requirements:
> > "A key aspect for the success of the ebXML initiative is adherence to
> > the use of the W3C suite of XML and related Web technical
> > specifications.  Although these specifications may not provide the
> > optimal technical solution, acceptance of ebXML by the business
> > community and technical community is tied to XML.  Alternative
> > technologies and technical specifications may be incorporated as part of
> > the ebXML solution.  However these alternative technologies and
> > specifications will only be provided as an alternative to the provided
> > XML solution unless the W3C XML and related Web technical specifications
> > can not accomplish the same business functionality."
> >
> > Kit.
> >
> > Todd Boyle wrote:
> > >
> > > I would appreciate any information or links regarding the duplicated
> > > or overlapping information in multiple layers of headers and wrappers.
> > > My understanding is that a typical ebXML message might contain
> > >
> > >   HTTP/MIME multipart/related header
> > >     ebXML header
> > >     payload1
> > >       Biztalk, or MSMQ/MQseries etc. header
> > >       Biztalk, or MSMQ/MQseries etc. header
> > >          Rosetta, OAG, CBL2, etc. document
> > >              Rosetta, OAG, CBL2, etc. required document header
> > >                  The XML message content which would usu. include
> > >                  all the parties' identities and reference codes
> > >     payload2
> > >     payload3   etc.
...

--
    _/    _/             Kit C. J. Lueder
   _/   _/         _/   The MITRE Corp.         Tel:  703-883-5205
  _/_/_/    _/  _/_/_/ 1820 Dolley Madison Bl  Cell: 703-577-2463
 _/   _/   _/    _/   Mailstop W722           FAX:  703-883-7996
_/    _/  _/    _/   McLean, VA 22102        Mail: kit@mitre.org
Worse than an unanswered question is an unquestioned answer.