RE: XML CDATA sections ... the good, the bad, and the ugly

The XML parser is only one oracle in the string.  A string it is anyway.   A CDATA section can be useful precisely because it is interpreted locally.

XML is independent of scaling.  Only when you add semantics does it obtain locality.   This is important, IMO, to what Postal’s Law is as good or bad advice.  The opportunities for handling information efficiently vary by local controls required over network size and density.   As in the example of the tuned schema, where information must not only be transported it must be operationally correct, limited distribution limits the way one applies postel.  If you want to analogize as near and far or weak and strong relations among the schemas themselves, that works.

Links have to scale more than titles.  Postel focus™ ;) is a business focus.

len

-----Original Message-----
From: Costello, Roger L. [mailto:costello@mitre.org]
Sent: Friday, June 26, 2015 6:52 AM
To: xml-dev@lists.xml.org
Subject: XML CDATA sections ... the good, the bad, and the ugly

Hi Folks,

The CDATA section is a mechanism for disabling the normal interpretation of XML syntax. For example, the title element in this XML document contains a script element:

<title>
    <script>...</script>
</title>

The title element in this XML document contains a string:

<title>
    <![CDATA[<script>...</script>]]>
</title>

Ordinarily <script> would be interpreted as a start tag but since <script> is embedded within a CDATA section the normal interpretation is disabled and <script> is treated simply as a string.

There is nothing that XSLT programs can do about CDATA sections. That is because the XML parser removes the CDATA wrapper and creates a text node for its content. The CDATA wrapper is gone by the time the XSLT program gets the XML; all that remains is a text node.

Nonetheless, some XSLT processors can be configured to instruct its XML parser to remove the CDATA sections. The approach for doing this varies with the XSLT processor. This article describes the approach used by one XSLT processor: http://sourceforge.net/p/saxon/mailman/message/34240016/.

Any errors in this description? Anything you would add or delete?

/Roger