As a quick fix I wrote the following XSLT file to fix all those confusing xml "empty" elements. This XSLT file will rewrite all empty "descr", "errors" and "seealso" elements to the following format. <node />
Here is how you can apply the XSLT under Linux. xsltproc -o output.xml remove_whitespace.xsl ticriteria.xml PS: Searching the internet it seems the XML preferred format for a empty element is a single tag with a '/' at the end. I guess we need to modify 'makeskel' then to output the correct/preferred format. Regards, - Graeme - On 2/13/07, Graeme Geldenhuys <[EMAIL PROTECTED]> wrote:
Hi, I asked this before, but got no reply. Generating new documentation in my projects I noticed the problem again, so here is the question again. Using 'makeskel' against a unit it generated this snippet. --------------------- BEGIN -------------------------- <!-- enumeration type Visibility: default --> <element name="TCriteriaType"> <short/> <descr> </descr> <seealso> </seealso> </element> --------------------- END -------------------------- Loading the relevant .xml file with LazDoc, it shows that this element has been documented (icons in the treeview have the letter 'T' on them). Actually, it shows that the whole unit has been fully documented, but one can clearly see that in hasn't been documented at all! Changing that code snippet to the following solves the problem. It seems that if the xml start/end node pair are split over two lines LazDoc thinks it has documentation added. Is this a issue with LazDoc interpretting the xml incorrectly, or is this a issue with 'makeskel' generating the skeleton xml incorrectly. So basically which one is to blame for this anomaly? Is a xml node where the start/end tags appear on separate lines considered having data or still considered being empty? --------------------- BEGIN -------------------------- <!-- enumeration type Visibility: default --> <element name="TCriteriaType"> <short/> <descr></descr> <seealso></seealso> </element> --------------------- END -------------------------- -- Graeme Geldenhuys There's no place like S34° 03.168' E018° 49.342'
-- Graeme Geldenhuys There's no place like S34° 03.168' E018° 49.342'
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"; version="1.0"> <xsl:output method="xml" omit-xml-declaration="no" indent="yes"/> <xsl:strip-space elements="descr"/> <xsl:strip-space elements="errors"/> <xsl:strip-space elements="seealso"/> <xsl:template match="@*|node()"> <xsl:copy> <xsl:apply-templates select="@*|node()"/> </xsl:copy> </xsl:template> </xsl:stylesheet>
