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


Nikola:

<SNIP>
> With most parser implementations a pure XML encapsulation would only allow
> the use of SAX parsing to avoid processing the entire message.
</SNIP>

Whoa!! This is bogus.  In the context of valid XML, both SAX and DOM must
parse the entire docoment to compare it with the schema/DTD to ascertain
whether or not it is valid.  A SAX parser can stop parsing if it encounters
syntax error in well formed /valid XML.  You are talking about parsing, not
handlers for encountered instances.

<Nikola>
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.</NIKOLA>

This would constitute an XML message.  It is redundant to mention an XML
message and XML payload.

<NIKOLA> 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.</NIKOLA>
First of all,  you cannot declare binary data as CDATA.  Any handlers will
puke on the input.  "Embed" is a member function of the XLink:show namespace
which issues a direction to include the referenced data into the document.
If the XLink:actuate is selected to "onLoad", your handler will try to
interpret pure binary data.  The MIME type for XML is Text.  Third - I
cannot think of any rational how a 30mb image file can possibly be
considered part of an XML e-business transaction.  It could be the "subject"
of the transaction, but XML is a text language.

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

I believe that TCP/IP - HTTP is the basis for which this will be built.  The
protocol MUST be O/S and Platform independant.  We cannot accept anything
less. HTTP has many of the built in error handling routines we need for
ebXML and is also easily integrated with security protocols.

<NIKOLA>
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?</NIKOLA>

Which XML Parser?  If you are referring to the Perl parser (XML::Parser),
the parser is built on top of James Clark's XPat parser in C.  The parser
does not actually embed the link.  It just reads the text.  It is the
handlers that act upon the parsed XML that perform this functionality.
Therefore, a link to a 30 mb file will parse just as quickly as a link to a
1 mb file.

If you are building the message blocks for transporting,  the construction
of the messaging can be a very important aspect for efficiency.  I do not
think you should force people to use either DOM or SAX as part of a design
rule.



[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