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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-architecture message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: Regarding the Thursday ebXML Conf Call


I've just read that XML (based on Unicode) declares 29 of the 256 8-bit characters to be illegal (e.g. '0000 0000'). My assumption
would then be that even within a CDATA section, if one of those 29 characters is encountered, the parser will generate an error.
Chances are very real that when you enclose a binary in a CDATA section some of the characters will be illegal XML characters.
Now if all of the above is true, how to enclose e.g. a binary in an XML document?
My best reply would be to use an encoding mechanism such as base64 to convert the bitmap into an XML Unicode compliant text.
Or am I missing a point here somewhere?


Duane Nickull wrote:

> 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.
> 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.
> 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.
org:S.W.I.F.T. sc;Standards
title:Product Manager Standards Automation
fn:Kris Ketels

[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