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

["Kit (Christopher) Lueder" <kit@mitre.org>]

Let's not get too defensive here...I raised the issue of MIME not being
a W3C standard a month ago, and when I saw that the group had proceeded
with a different design despite that issue, I raised the issue again. If
you think the issue was wrong, you should have escallated it to the
ebXML Requirements group where it originated, rather than ignoring it.

I don't see why "There is no XML based standard for packaging mixed
payloads" means you must go with a MIME solution rather than creating an
XML packaging standard? Also, I thought BizTalk was a pure XML packaging
standard, so this statement wasn't really true?

Regarding "MIME is not that difficult to process", how hard is it for a
web server to generate MIME envelopes along with the XML content after
the user has filled in a web form (or what ever method for triggering
the generation of XML content)? (This is a serious question, not a
criticism...)

Sincerely,
Kit.

Dick Brooks wrote:
> The packaging sub-group has spent several weeks coming up with this design
> and now it seems some people want to "unravel" it and start all over again.
> If we keep revisiting and rehashing decisions we will not meet our
> deadlines.
> 
> The packaging sub-group discussed one container versus two and the reasons
> we decided on two containers follow:
> 
> - One XML container means that the entire document (which could be GIGABYTES
> of data) would have to be processed/parsed as a single XML document. This
> would make processing time slow and could seriously impact response time.
> 
> - There is no XML based standard for packaging mixed payloads. The ebXML
> group would have to create a XML based packaging standard and this didn't
> seem practical when we could very easily apply MIME to a task it was well
> designed to handle. this also met the group requirement to use existing
> solutions whenever possible (don't re-invent the wheel).
> 
> - There is a large installed base of products that support MIME and
> developers who are familiar with MIME. Scott, MIME is not that "difficult"
> to process - I'll bet I could teach you how to process the ebXML MIME
> envelope in less than two hours using MIME++, assuming you're familiar with
> C++ ;^).
> 
> I assert that a MIME solution using two "containers", is superior to a
> single XML container for for the following reasons:
>         - there are no illeagal characters to deal with in MIME as there are in XML
> (&amp &lt all have to be transformed)
>         - there are mature, proven packages available to parse MIME, an XML
> solution would have to be developed
>         - binary objects are transportable without any conversion with MIME (no
> base64 needed when using HTTP transport);
>         with XML binary objects must be base64 encoded
>         - applying base64 to a payload adds appx 40% to its size and this adds time
> to transmit and process.
>         - There are already MIME based STANDARDS for packaging a significant body
> of objects (jpeg, EDI, XML, html, et al), these would all have to be created
> for an XML based packaging solution.
> 
> Some people have suggested using the existing MIME headers and media types
> to create an XML packaging specifcation, then we could have MIME in XML.
> Why - what is the benefit of this - the ability to say we have a pure XML
> packaging solution?
> 
> The packaging sub-group is certainly open to a better solution - if one
> exists. Please announce to the list any STANDARD based XML packaging
> solutions that we should consider, please be sure to include how the issues
> above are addressed.
> 
> Thank you,
> 
> Dick Brooks
> http://www.8760.com/


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