[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Tradeoffs of XML encoding by enclosing all content in CDAT

  • From: "Fraser Goffin" <goffinf@g...>
  • To: xml-dev@l...
  • Date: Tue, 30 Sep 2008 09:32:43 +0100

Re:  Tradeoffs of XML encoding by enclosing all content in CDAT
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. This makes it quite difficult for designers to argue against
this approach as the OP suggests when faced with that challenge.

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

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. Consider also that some of these may be packaged
applications where the organisation may not have access to the source
code and/or may not want to commit to enhancing it. Perhaps this is a
case for a mediation layer ?


2008/9/30 Felix Sasaki <fsasaki@w...>:
> Not main arguments, but maybe still of interest:
> http://www.w3.org/TR/xml-i18n-bp/#AuthCDATA
> Felix
> Karr, David さんは書きました:
>> I pointed out to a client that they're seeing failures parsing XML because
>> some of the element content that they're producing contains characters
>> illegal in XML content, like "&" (unencoded). They acknowledged that should
>> be fixed, but they also said they could instead enclose all content with
>> CDATA blocks. That seems bizarre to me, but I'm not sure I can immediately
>> come up with all the cogent arguments against that. Can someone summarize
>> specifically why you should NOT do that?
> _______________________________________________________________________
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@l...
> subscribe: xml-dev-subscribe@l...
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.