W3C home > Mailing lists > Public > xml-dist-app@w3.org > October 2000

RE: Issues with Packaging Application Payloads

From: HUGHES,MARK (Non-HP-FtCollins,ex1) <mark_hughes@non.hp.com>
Date: Wed, 18 Oct 2000 17:15:20 -0400 (EDT)
Message-ID: <C5C45572D968D411A1B500D0B74FF4A801A30D@xfc01.fc.hp.com>
To: xml-dist-app@w3.org
> From: Laird A Popkin [mailto:laird@io.com]
> It seems to me that the problem with transporting arbitrary 
> XML content in
> XML messages is that there is no way to easily encapsulate 
> arbitrary XML
> within XML and validate it.

  There most certainly is, see below.

> The strategies I can think of are:
> 1) Include the "body" as arbitrary data, terminated by ]]>. 
> 2) The other strategy is to base64 encode the contained message, which
> 3) Include the "body" as content type ANY, so it has to be 

  Then there's #4, the *RIGHT WAY* to do this, which is:
A) Before inserting your arbitrary text into your XML wrapper, run it
through a filter that replaces & with &amp;, < with &lt;, and > with &gt;.
B) Before handing arbitrary text back to the user, run it through a filter
that replaces &lt; with <, &gt; with >, and &amp; with &.

  Voila, the problem is solved.  You don't have the byte bloat of base64,
you don't have the limitation of not including ]]> in CDATA, and you don't
have to mess up validation.

  XML is 8-bit clean (through UTF-8/16), so you can even send binary this
way (though admittedly, at 50% bloat for 128-255, as compared to the 33%
bloat of base64).

  It's easy.  It's nigh-perfect.  Why would anyone NOT do this?

-- 
 <a href="http://kuoi.asui.uidaho.edu/~kamikaze/"> Mark Hughes </a>
Received on Wednesday, 18 October 2000 18:27:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:57 GMT