1

From my research, there seems to be no way for an xsd to spawn CDATA tags in a specified element. I understand this may be a limitation of the XSD spec, and I am fine moving to some other workflow to solve this.

The problem, in our current XSD workflow, is that we have to add the CDATA tag by hand. This one element is a block of HTML, and we have to escape it. Our XSD --> XML workflow is this a bit messy as a result, as we find ourselves needing to add the CDATA tag by hand.

What is the suggested workflow/solution?

(In VSCode, we are creating XML files by hand from an existing XSD -- we could convert to DTD or other template format if that helps. This is not really an XSD question [unless you have new information about XSD...] This is a "how should we rethink our approach to meeting our needs" question.)

Jonesome Reinstate Monica
  • 6,618
  • 11
  • 65
  • 112
  • Does this answer your question? [How do i designate in XSD that an element only contains CDATA?](https://stackoverflow.com/questions/175695/how-do-i-designate-in-xsd-that-an-element-only-contains-cdata) – xerx593 Dec 19 '21 at 22:13
  • 1
    @xerx593 Thanks! That does not help. I am fine changing our workflow or approach, even dumping XSD in favor of something else, but I need a way to remove the "human must remember to past in tag" part of our workflow... – Jonesome Reinstate Monica Dec 19 '21 at 22:30
  • @xerx593 OP enhanced – Jonesome Reinstate Monica Dec 19 '21 at 22:39

3 Answers3

1

The design assumption in XSD is that CDATA tags have no information content: writing <a><![CDATA[Tate & Lyle]]></a> is precisely equivalent to writing <a>Tate &amp; Lyle</a> and no application should require you to write one of these forms in preference to the other. So XSD is trying to encourage good practice by not making any distinction between them. If you want to ignore (this idea of) good practice by making such a distinction, XSD isn't going to help you, by design.

Michael Kay
  • 156,231
  • 11
  • 92
  • 164
0

Here is a solution for you. Just use an XSLT Transformation that is following a so called Identity Transform pattern.

Most important XSLT allows to specify what XML element(s) require a CData section.

The cdata-section-elements attribute allows to define a space-separated list of XML element names. Each of these elements are output as CDATA sections in the target document.

Check it out below. The XSLT specifies that the <title> element value needs a CData section.

It is documented here: http://www.w3.org/TR/xslt20/#serialization

XSLT

<?xml version="1.0"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:g="http://base.google.com/ns/1.0">
   <xsl:output method="xml" indent="yes" cdata-section-elements="title" encoding="utf-8" omit-xml-declaration="no"/>
   <xsl:strip-space elements="*"/>

   <xsl:template match="@*|node()">
      <xsl:copy>
         <xsl:apply-templates select="@*|node()"/>
      </xsl:copy>
   </xsl:template>
</xsl:stylesheet>
Yitzhak Khabinsky
  • 18,471
  • 2
  • 15
  • 21
0

As pointed out by others, there's no way in XSD or XML DTDs to require element content to be parsed as CDATA, or infer (rather than write individually) CDATA section markers around element content. For what it's worth, SGML DTDs, on the other hand, do allow an element to have declared content CDATA (or RCDATA), which makes SGML treat the respective content as unparsed character data, that is by ignoring markup delimiters like < and (for CDATA but not RCDATA) the entity reference start character &. Having CDATA declared content available is necessary for parsing HTML eg. inline CSS or script containing characters that would otherwise be interpreted as markup delimiters.

Pointing this out because your stated goal is to include verbatim HTML, which won't work using XML since HTML uses features not available in the XML subset of SGML, such as tag omission, empty elements, and attribute shortforms, among others.

imhotap
  • 2,275
  • 1
  • 8
  • 16