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.)
CodePudding user response:
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>
CodePudding user response:
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 & 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.