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 < and > 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 <br>
<xsl:if test="../@type='house_cottage'">type: a house or
cottage<br></xsl:if>
<xsl:if test="../@type='for_horticulture'">type: a structure for
horticulture<br></xsl:if>
<xsl:if test="../@type='caravan'">type: a
caravan<br></xsl:if>
<xsl:if test="../@type='oldcontainer' ">type: an old
container<br></xsl:if>
<xsl:if test="../@type='bender'">type: a
bender<br></xsl:if>
<xsl:if test="../@type='portacabin'">type: a
portacabin<br></xsl:if>
<xsl:if test="../@type='yurt' ">type: a
yurt<br></xsl:if>
<xsl:if test="../@type='wigwam'">type: a
wigwam<br></xsl:if>
<xsl:if test="../@type='roundhouse' ">type: a
roundhouse<br></xsl:if>
<xsl:if test="../@type='logcabin' ">type: a log-cabin
design<br></xsl:if>
<xsl:if test="../@type='treehouse' ">type: a
tree-house<br></xsl:if>
<xsl:if test="../@type='civilengineering' ">type: a 'civil
engineering' structure<br></xsl:if>
<xsl:if test="../@type='adhocdesign' ">type: an 'ad-hoc'
design<br></xsl:if>
for human habitation? : <xsl:value-of select="../@forhumanhabitation"/><br>
legally a tempoary structure? : <xsl:value-of
select="../@temporarystructure"/><br>
<![CDATA[
</strong></td>
</tr>]]>
</xsl:if>
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--