[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [Fwd: Re[2]: Concern with basic ebXML TRP Syntax/Semantics]
Bob, Please provide details showing how a PGP or S/MIME signed/encrypted payload is supported in your proposal. FYI, Everyone in the packaging sub-group knows it's possible to paste together various payloads into a pure XML document, we have seen some solutions to this problem (XMTP is one example) - IT CAN BE DONE AND WE KNOW HOW TO DO IT, BUT: - The pure XML solution is equivalent to reinventing MIME headers and registered content-types as a set of XML elements and attributes - The solution is not an accepted industry standard (IETF or W3C) - it's kludgey - due to the number of transforms required (base64 encoding + illegal character conversion "& and < ") - pure xml approaches break when xml structures are embedded in plain/text payloads - it confuses XML parsers - The benefits of a pure XML solution are not apparent and it's difficult to justify the time needed, and ultimate delay, while a pure XML packaging solution is being developed. Consider the fact that companies KNOW they can simply send their XML payloads via existing e-mail or HTTP so why should they wait - they can send/receive XML payloads NOW using existing tools! In summary, the packaging group knows it's possible to create a "pure XML" packaging solution! But it's not easy and, most importantly, it's not standard. If we were to invest the time/energy to create a pure XML solution, several months from now, when we're finished, we'll have the equivalent of MIME, but it will be far more complicated to implement due to the transforms needed to make payloads "legal XML" and it will end up being transported via SMTP or HTTP in a MIME envelope! What's the point! The question you must ask yourself is: Why should we invest a significant amount of time to recreate MIME as XML when the end result is something that is more complicated and less functional that MIME, why not simply use MIME? What is the advantage of being "pure XML"? Someone please answer this question - I'm stumped! Dick Brooks http://www.8760.com/ ----- Original Message ----- From: Miller, Robert (GEIS) <Robert.Miller@geis.ge.com> To: <ebXML-Transport@lists.oasis-open.org> Sent: Tuesday, April 11, 2000 8:39 AM Subject: RE: [Fwd: Re[2]: Concern with basic ebXML TRP Syntax/Semantics] > Gentle People, > > Could we get to a single XML document with reasonably small risk of XML > parser failures beyond the ebXML header if we defined something like: > > <!ELEMENT ebXML (ebXMLHeader,ebXMLbody*)> > <!ELEMENT ebXMLHeader ( ... )> > <!ELEMENT ebXMLBody ANY> > > or for the 'body' parser, > > <!ELEMENT ebXML (ebXMLHeader,ebXMLbody*)> > <!ELEMENT ebXMLHeader ANY> > <!ELEMENT ebXMLBody ( ... )> > > Or perhaps the <ebXML> element could invoke some sort of XSLT filter that > blew apart the document into standalone header and body XML files and > invoked processing of the parts. (NOTE: I'm not an XML guru, so I might > just be blowing smoke here!) > > Cheers, > Bob
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC