Re: Regarding the Thursday ebXML Conf Call

[KETELS Kris <kris.ketels@swift.com>]

All,

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?

regs
kris


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.
>
> <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.
begin:vcard 
n:Ketels;Kris
tel;fax:+32.2.655.45.52
tel;work:+32.2.655.44.85
x-mozilla-html:FALSE
org:S.W.I.F.T. sc;Standards
adr:;;;;;;
version:2.1
email;internet:kris.ketels@swift.com
title:Product Manager Standards Automation
x-mozilla-cpt:;1
fn:Kris Ketels
end:vcard