thread 2) Re: [XML-SIG] CDATA sections still not handled

Fri, 19 Jan 2001 09:47:57 +1300

On Fri, 19 Jan 2001, Norman Walsh wrote:
> / matt <> was heard to say:
> | happend to use things like "<" very often, then CDATA seems to give me and
> | "initial" way to write this in a plain, raw form, without translating it to
> | entity references first.
> In the interest of technical accuracy, I'll point out that there's nothing
> that says a processor is not allowed to use CDATA to escape text. (It might
> be an interesting switch on a serializer: use CDATA for any text node that
> contains more than 5% entity references or something...)
> | > Don't do that. I'm serious. You don't say exactly what problem you're
> | > trying to solve, but the solution you're outlining is ugly and
> | > fragile. (IMHO, naturally.)
> | 
> | No it's not.  If I put base64 encoded gzip compressed versions of the same
> | "escaped xml fragments" that I want to hide, then that would seem to make you
> | happy.  These xml documents are a transport, and when a transpot is interpreted
> | then certain tags may mean do something with the character data of this node. 
> | All seems pretty normal to me.
> Ok, perhaps I overstated the case. I should have said something like "in
> most cases that's going to be ugly and fragile".
> XML isn't particularly good at wrapping up other chunks of XML. Using
> CDATA sections is dangerous if there's any chance that the text you're
> wrapping up might contain "]]>". For example, if one of the documents
> that you're wrapping up has its own CDATA section.

Is it perhaps cleaner to use xlinks for the message nodes?  I haven't used these
yet, but I gather it would seperate transport from message.  Though to maintain
performance a server would have to parse it first to see what to transport in
the same network connection.  

> | through it and find the improper formatting in the message.  However, if the
> | message has been translated into entity references, then forget it, you may as
> | well be looking at binary in a hex editor in some instances. 
> Yes. That's a problem. Maybe you need that special-purpose serializer
> I alluded to above.
>                                         Be seeing you,
>                                           norm
> -- 
> Norman Walsh <> | It is not impossibilities which fill us
>            | with the deepest despair, but
>                               | possibilities which we have failed to
>                               | realize.--Robert Mallet