Re: [xsl] CDATA Handling

Subject: Re: [xsl] CDATA Handling
From: Ken Starks <ken@xxxxxxxxxxxxxxxxxxxxx>
Date: Tue, 06 Jan 2009 12:59:23 +0000
David Carlisle wrote:
Basically they don't want to change the DTD and wants the data to be parse by the existing DTD.

It is impossible to specify in a DTD that CDATA sections are used, just as it is impossible to say that you have to use " rather than ' around attribute values. CDATA sections are just part of the lexical syntax layer: a DTD validator does not see if they are used or not, just as XSLT does not see if they are used.

If <x><![CDATA[abcde]]></x> is DTD valid, then so is <x>abcde</x> as it is identical input.


Michael Kay wrote:

> >I guess the definition of professionalism is that if you're a > >professional, you advise the client when he gets the requirements > >wrong, and if you're not, you build whatever rubbish he asks for.
I have a similar problem, and its time to name names. I am writing an
application to produce KML, which is the 'keyhole markup language' of Google Earth and Google Maps from my home-designed XML. ( It uses
Apache cocoon, and actually it creates several other formats also.)

The KML Schema has a <description> element in which a limited
subset of HTML is 'permitted', normally written as CDATA. This 'limited subset' of HTML is set out in a sample document, not a Schema or DTD. In other
words it is a really <expletive type="deleted"> ***** </expletive> design.

Almost anything will validate, so it is error-prone to find and correct unbalanced or otherwise invalid HTML elements. When the output is not CDATA
and you are also faced with lots of &lt; and &gt; it is horrendous. Technically
(David) it is indeed 'identical input' for the Google Earth software, but not when it is input to me, a human reader.

Google is not my client! As I don't really feel either able or willing to rewrite their Schema for them, I feel it would just be cheeky to complain
too hard, and against open-source ethos.

At present my policy is:
1. To make my own home-made Schema as readable as possible.
2. To ignore, with regret, the fact that the final KML output is more-or-less unreadable by humans. To advise my clients not even to try to understand it,
just to trust me.
3. To attempt to make my XSL-T more or less readable by my client's own geeks, so
they can modify it if they wish. This is where I would appreciate advice from this
group. Is the following 'more-or-less readable' ? or how could it be improved ? (I jump in and out of CDATA with wild abandon)

The example fragment of XSL-T starts of in the middle of an HTML table:

<xsl:if test="local-name(parent::node())='BuiltStructure'"><![CDATA[
Built Structure &lt;br&gt;

<xsl:if test="../@type='house_cottage'">type: a house or cottage&lt;br&gt;</xsl:if>
<xsl:if test="../@type='for_horticulture'">type: a structure for horticulture&lt;br&gt;</xsl:if>
<xsl:if test="../@type='caravan'">type: a caravan&lt;br&gt;</xsl:if>
<xsl:if test="../@type='oldcontainer' ">type: an old container&lt;br&gt;</xsl:if>
<xsl:if test="../@type='bender'">type: a bender&lt;br&gt;</xsl:if>
<xsl:if test="../@type='portacabin'">type: a portacabin&lt;br&gt;</xsl:if>
<xsl:if test="../@type='yurt' ">type: a yurt&lt;br&gt;</xsl:if>
<xsl:if test="../@type='wigwam'">type: a wigwam&lt;br&gt;</xsl:if>
<xsl:if test="../@type='roundhouse' ">type: a roundhouse&lt;br&gt;</xsl:if>
<xsl:if test="../@type='logcabin' ">type: a log-cabin design&lt;br&gt;</xsl:if>
<xsl:if test="../@type='treehouse' ">type: a tree-house&lt;br&gt;</xsl:if>
<xsl:if test="../@type='civilengineering' ">type: a 'civil engineering' structure&lt;br&gt;</xsl:if>
<xsl:if test="../@type='adhocdesign' ">type: an 'ad-hoc' design&lt;br&gt;</xsl:if>
for human habitation? : <xsl:value-of select="../@forhumanhabitation"/>&lt;br&gt;
legally a tempoary structure? : <xsl:value-of select="../@temporarystructure"/>&lt;br&gt;

Current Thread