OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[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]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC