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: RE: Regarding the Thursday ebXML Conf Call

> The problem that is being addressed by mime encapsulation only arises when
> there is a need to transmit multiple XML Message bodies and provide
> for arbitrarily large binary objects (i.e. images). Most participants
> to agree that this type of mixed transmission would not be well suited to
> further encapsulation in another XML envelope. A case was sited were only
> one of the messages is desired out of a potentially large multi-part
> With most parser implementations a pure XML encapsulation would only allow
> the use of SAX parsing to avoid processing the entire message.

I am not sure that this would be possible, but just thinking loudly. Would
this work?

For large files:
1) Compose a XML msg where payload is XML as well. Payload is user specific
so it might be that some of them would need to transfer 30MB image file.
That file could be embedded (CDATA) or it could be referenced (URI) or
whatever else.
2) Send it via ANY reliable protocol. Who cares about packets; requirement
is that the whole XML msg is going to be delivered to the receiving end.
3) Use XML parser on receiving side. If SAX, go to manifest and find that
there is a big file in the payload. Save it somewhere. If DOM good luck?

For recursive "EnvelopeAsAPayload" pattern:
1) On receiving end while digesting manifest, discover that payload has
another envelop(s). Process those recursively.

In both cases MIME is possible, but not required. Anyway, this might be a
good candidate for an early prototype (proof of concept)?


[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