{"id":11292,"date":"2026-07-10T16:37:27","date_gmt":"2026-07-10T11:07:27","guid":{"rendered":"https:\/\/4ksamachar.com\/?p=11292"},"modified":"2026-07-10T16:37:27","modified_gmt":"2026-07-10T11:07:27","slug":"dennis-snell-see-data-cdata-rcdata-and-pcdata-oh-my","status":"publish","type":"post","link":"https:\/\/4ksamachar.com\/?p=11292","title":{"rendered":"Dennis Snell: See DATA, CDATA, RCDATA, and PCDATA oh my!"},"content":{"rendered":"

HTML and XML are markup languages based on plaintext files. This means that any given character could<\/em> be part of a syntax form (a tag, a comment, a character reference, etc\u2026) or<\/em> it could be representing itself the way it reads in the file literally.<\/p>\n

\n
\n
\n
\n
<<\/span>tag<\/span>><\/span>&middot;<\/span> Text node<\/<\/span>tag<\/span>><\/span><\/div><\/code><\/pre>\n<\/p><\/div>\n<\/p><\/div>\n<\/div>\n
Whenever a character might be ambiguous, both languages require explicit indication of the intent of the character. In HTML this occurs via escaping<\/em>, while XML allows escaping or<\/em> wrapping the content in a marked section<\/em>, specifically a CDATA section<\/code>.<\/p>\n
\n
\n
\n
\n
&lt;<\/span>tag&gt;<\/span><\/div>
<![CDATA[<tag>\u00b7 Text node<\/tag>]]><\/span><\/div><\/code><\/pre>\n<\/p><\/div>\n<\/p><\/div>\n<\/div>\n
These terms confuse me at times, especially since CDATA<\/code> and CDATA sections<\/code> are distinct forms of the same content, and it\u2019s easy to conflate each term. This post is here to disambiguate the terms, their meanings, and why they exist.<\/p>\n
The punchline comes at the end<\/a>, but the story is hopefully worth the read.<\/p>\n
<\/span><\/p>\n
Markup and mixed content<\/h2>\n
One of the first jobs of a parser for any plaintext-oriented format is to determine if the next input character represents real text or is part of a syntax form that carries special meaning. If it\u2019s a syntax form we would call it markup<\/em>, but if the characters are part of real text meant for display or rendering or reading then we call it data<\/em>.<\/p>\n
Anything that is not syntax is data.<\/p>\n
The interpretation of the next character depends on the region of the document in which it\u2019s parsed. While the rules for syntax forms are complicated1<\/a><\/sup>, this post will focus on the data forms.<\/p>\n
PCDATA \u2014 \u201cparsed character data\u201d<\/h3>\n
May form: tags, comments, sections, character references, literal text.<\/em><\/p>\n
Characters in this region could be data or could form the start of a new markup element. It\u2019s \u201cparsed\u201d because it needs parsing before determining what it represents.<\/p>\n
The HTML specification renames this to Data<\/code>, which is simpler and a bit harder to search for. In XML, however, it\u2019s used in a document-type definition (DTD). When an element may contain content \u2014 text \u2014 its data model must include #PCDATA<\/code>. Otherwise the only characters allowable within that element are other elements, comments, and whitespace. XML documents are required to be valid SGML documents, so its own specification adopts the terminology from SGML\u2019s.<\/p>\n
Those who have worked with DTDs might note that elements<\/em> in XML may contain #PCDATA<\/code> while attributes<\/em> contain CDATA<\/code> instead. First of all, the #<\/code> is there only to make it explicit that PCDATA<\/code> is referring to the reserved keyword, rather than a <pcdata><\/code> element. Secondly, there\u2019s a good reason for this, which is that attributes can only contain text \u2014 they can\u2019t contain other elements of markup. If an attribute value could contain a <span><\/code> element, for example, then the attribute value would need to be #PCDATA<\/code> instead, but this is prevented by design.<\/p>\n
PCDATA actually contains more than just literal text and elements. In addition to comments, processing instructions, and other node-like syntax, one important feature of PCDATA is the character reference<\/em>. These make it possible to represent characters that would conflate with syntax (such as \u2018<<\/code>\u2019 \u2014 &lt;<\/code>) or which might be cumbersome to enter on a keyboard (such as \u2018\u00a7\u2019 \u2014 &sect;<\/code>). When parsing, each character in these sequences neither creates an element nor  displays as the text itself; rather, the entire sequence is parsed and translates into the character it refers to.<\/p>\n
HTML pre-specifies a fixed set of named character references<\/a>, but any Unicode code point may be referenced by its decimal or hexadecimal numeric index. While XML also allows referencing code points by their index2<\/a><\/sup>, it only pre-specifies the five named characters which correspond to its main markup introducers: <<\/code>, ><\/code>, &<\/code>, '<\/code>, and \"<\/code>. In XML, any additional named character references are created through the DTD by defining entities<\/em>.<\/p>\n
 CDATA \u2014 \u201ccharacter data\u201d<\/h3>\n
May form: [character references], literal text.<\/em><\/p>\n
If a character isn\u2019t markup, then it\u2019s character data<\/em>, which means that it\u2019s representing its literal self or it\u2019s part of a character reference<\/em>. Once the parser has entered this region it will not create markup elements.<\/p>\n
CDATA is the most confusable kind of character data; this is because there are many kinds of CDATA that share the same name:<\/p>\n