Cart
[Home] [By Thread] [By Date] [Recent Entries]
> 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 & and <. 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/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
