Re: [xml-dev] Tradeoffs of XML encoding by enclosing all content in CDAT

["Fraser Goffin" <goffinf@googlemail.com>]

> ... Using CDATA only becomes easier
> if you do it incorrectly, and surely you're not proposing to do that?

No I (like Rick) am talking about pragmatism. Sometimes it is possible
to reason about the likely occurence of edge cases such as ]]> as well
as the more obvious cases such as &. That reasoning may lead you to
conclude that it *is* in fact easier to use CDATA ("incorrectly" or
perhaps "incompletely") much in the same way that we reason about all
kinds of other risks where the cost of fixing every eventuality isn't
justifiable.

> Do what some UK government applications do: tell the user you can't use "&" ...

Well, my point was that sometimes this might not be and available
(and/or affordable) option.

> ... and the vast majority will think you are just being bureaucratic,
> which is what they expect of you anyway. But since they don't have the
> option of taking their business elsewhere, why should you care?

I would prefer to be a little more helpful than that and, whilst I
agree entirely with your later post [(a) prevent it happening if you
can], sometimes option (b) is what you are left with (I'm certain you
are familiar of the multitude of reasons why this might be so, I have
hinted at some of them already).

Fraser.

2008/9/30 Michael Kay <mike@saxonica.com>:
>
>> Whilst I am pretty much in agreement with all of the
>> sentiments expressed here, its interesting that no one has
>> really come up with a compelling argument for not using CDATA
>> to resolve this encoding issue.
>
> I thought several people had pointed out that escaping data with CDATA
> correctly (which means recognizing ']]>' and possibly comments) was harder
> than escaping the data using &amp; and &lt;. Using CDATA only becomes easier
> if you do it incorrectly, and surely you're not proposing to do that?
>
>> So as a provocation, I integrate with many back office
>> applications a number of which were written before I was born
>> and they are still going strong and supporting core business
>> capabilities. Many are written in languages that don't
>> natively support XML, run on all manner of platforms, and are
>> maintained by programmers who have no skill in XML at its
>> relations or (as they might perceive it) need to acquire it.
>> Such applications typically *do* just output XML as a string.
>>
>> Before we dismiss these applications as useless because they
>> don't natively support XML and suggest that there keepers are
>> 'lazy', what does the group suggest is the best approach to
>> maintaining the correct encoding.
>
> Do what some UK government applications do: tell the user you can't use "&"
> or "<" in text fields, and reject the data if you find them being used. This
> means that a very small minority of users will know you are technically
> incompetent (or at any rate, that you employ "programmers who have no skill
> in XML"), and the vast majority will think you are just being bureaucratic,
> which is what they expect of you anyway. But since they don't have the
> option of taking their business elsewhere, why should you care?
>
> Michael Kay
> http://www.saxonica.com/
>
>