[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: XML based Manifests vs Multi-part-related MIME encoding of mu lti-part messages
Hi, I believe there are SAX parsers available already. I see the primary problems that need to be solved by either approach, i.e. MIME/XML based packaging as, 1. The ability to pack together varying number of, disparate content types(xml and non-xml including binary forms), without having to resort to special conversion / data encoding schemes (e.g. binary to UUENCODE). 2. To keep business content independent of and disjoint from routing information so that, entities performing the routing (potentially third parties), don't need to (or should not) look into the business message. 3. Facilitate detection and reporting of errors back to the originating party (by the receiving party), even if the business content is not something handled by the receiving party. That is, have a well defined standard header and variable business content, that are packed together. We have seen examples and real uses of MIME bases solutions for all of the above. We are yet to see a "workable" XML based proposals.. Best Regards, Prasad -----Original Message----- From: David Burdett To: Matthew MacKenzie; Dick Brooks (E); Ravi Manikundalam; ebXML Transport (E-mail); rnif_v2@lists.rosettanet.org Sent: 3/13/00 7:59 AM Subject: RE: XML based Manifests vs Multi-part-related MIME encoding of mu lti-part messages Matthew/Kit et al Matthew says >>>XML Parser's can't stop in the middle of a document? <<< I agree. But if we said instead "**Current** XML Parser's can't stop in the middle of a document?" then their might be solution. Suppose there was a new type of XML parser that you could ask to just extract particular well formed sub-trees and ignore the rest, then wouldn't we have a solution to the problem as we could extract the header and leave the body unparsed (even if it had errors). The only problem is that you need to know **in advance** that you have an ebXML message, but we could do this at the transport or mime level, e.g.: 1. With a new MIME type: text/ebXML 2. With a transport parameter such as: message-type: ebXML Thoughts? David -----Original Message----- From: Matthew MacKenzie [mailto:matt@xmlglobal.com] Sent: Sunday, March 12, 2000 5:46 PM To: David Burdett; Dick Brooks (E); Ravi Manikundalam; ebXML Transport (E-mail); rnif_v2@lists.rosettanet.org Subject: RE: XML based Manifests vs Multi-part-related MIME encoding of mu lti-part messages > >Email by Kit Leuder ... > ><Kit> >Benefits of MIME envelope: > - If you are using e-mail, it falls out automatically. > - If you want to parse the header but don't want to parse the body >(content), XML parsers aren't able to arbitrarily stop in the middle of >a document. (e.g., if you have an ebXML envelope around a huge document >content and don't want the overhead of parsing the whole thing.) MIME >allows the header to be a separate attachment from the body, so they can >be parsed separately. XML Parser's can't stop in the middle of a document? If it is event based, it can. I stop dead in the middle of a parse quite often using expat, I am sure a SAX parser would allow this is well. You just kill the parser object when you have seen what you want to see. Cheers, Matthew MacKenzie XML Global Technologies, Inc.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC