[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: CDATA Handling

Subject: Re: CDATA Handling
From: Ken Starks <ken@xxxxxxxxxxxxxxxxxxxxx>
Date: Tue, 06 Jan 2009 12:59:23 +0000
Re:  CDATA Handling
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.

David


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[
<tr>
<td>Category</td><td><strong>]]>
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;
<![CDATA[
</strong></td>
</tr>]]>
</xsl:if>


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2011 All Rights Reserved.