[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: DOCBOOK-APPS: Overriding <para> template creates invalid HTML
On Thu, Jul 18, 2002 at 06:25:33AM -0700, Alex Lancaster wrote: > (Please Cc me on followups, because I'm not directly subscribed to the > list, but I get my access through the GMANE mail-to-news gateway, > which saves on a lot of disk space!) > > I seem to have stumbled upon an odd bug. I wanted to override the > default <para> match rule, but in certain contexts, I get invalid HTML > (extra '</p>' end tags). I then pared it down to the simplest test > case, and it turns out that even copying the *identical* para match > rule from "block.xsl" into a customization layer causes the problem. > Somehow the "unwrap.p" named-template gets defeated, causing invalid > HTML. > > This has been filed as bug #583335 at sourceforge: > > https://sourceforge.net/tracker/index.php?func=detail&aid=583335&group_id=21935&atid=373747 > > Here is the test case, "test.xml": > > <?xml version="1.0" encoding="ISO-8859-1"?> > <!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" > "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"> > <article condition="main"> > <title>test</title> > > <itemizedlist> > <listitem> > <formalpara> > <title>title</title> > <para>Some problem</para> > </formalpara> > </listitem> > </itemizedlist> > > </article> > > Here is the customization layer, "test.xsl" (note this simply a > cut-n-paste of the template from block.xsl): > > <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" > version='1.0'> > > <xsl:import > href="http://docbook.sourceforge.net/release/xsl/1.52.2/html/docbook.xsl"/> > > <xsl:output method="html" encoding="ISO-8859-1" > doctype-public="-//W3C//DTD HTML 4.01 Transitional//EN" > doctype-system="http://www.w3.org/TR/html4/loose.dtd" indent="no"/> > > <xsl:template match="para"> > <xsl:variable name="p"> > <p> > <xsl:if test="position() = 1 and parent::listitem"> > <xsl:call-template name="anchor"> > <xsl:with-param name="node" select="parent::listitem"/> > </xsl:call-template> > </xsl:if> > > <xsl:call-template name="anchor"/> > <xsl:apply-templates/> > </p> > </xsl:variable> > > <xsl:choose> > <xsl:when test="$html.cleanup != 0"> > <xsl:call-template name="unwrap.p"> > <xsl:with-param name="p" select="$p"/> > </xsl:call-template> > </xsl:when> > <xsl:otherwise> > <xsl:copy-of select="$p"/> > </xsl:otherwise> > </xsl:choose> > </xsl:template> > > </xsl:stylesheet> > > and here is the output (this fails a validation check at > validator.w3.org): > > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" > "http://www.w3.org/TR/html4/loose.dtd"><html><head><meta > content="text/html; charset=ISO-8859-1" > http-equiv="Content-Type"><title>test</title><meta name="generator" content="DocBook XSL Stylesheets V1.52.2"></head><body bgcolor="white" > text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div > class="article"><div class="titlepage"><div><h2 class="title"><a > name="id2775507"></a>test</h2></div><hr></div><div > class="itemizedlist"><ul type="disc"><li><p><b>title. </b><p>Some > problem</p></p></li></ul></div></div></body></html> > > With the following message: > > > Below are the results of attempting to parse this document with an > SGML parser. > > * Line 2, column 50: > > ... "disc"><li><p><b>title. </b><p>Some problem</p></p></li></ul></div></ ... > ^ > > Error: end tag for element "P" which is not open; try removing > the end tag or check for improper nesting of elements > Actually, this isn't a bug, it is an expression of the behavior of XSLT import precedence that shows up when you use formalpara/para. Here is what is going on. The stock <xsl:template match="para"> template wraps its content in <p> </p>, except when its unwrap process kicks in to avoid <p> tags where HTML doesn't like them. But the block.xsl file also has a template <xsl:template match="formalpara/para">. This template does not output <p> </p> at all, because it knows the wrapper formalpara element's template has already done that, so that the title and para are inside the <p> </p>. Because this template's match pattern is more specific, it has a higher priority that the "para" template. Now copy the "para" template to your customization layer and import docbook.xsl. The rules of import precedence state that the importing file's templates take precedence over the imported file's templates. In general, that's how customized templates override the stock ones. But what isn't obvious is that import precedence is stronger than priority selection. So your custom "para" template is used inside formalpara. The "formalpara/para" template has higher priority inside the stock docbook stylesheet, but not in the importing stylesheet. So you end up with nested <p> elements, which is not legal HTML. The solution is to add another template to your customization layer: <xsl:template match="formalpara/para"> <xsl:apply-imports/> </xsl:template> Now this template has higher priority than your custom "para" template in the importing stylesheet. Its effect is to use the imported stock "formalpara/para" template, which is what you want in order to avoid the extra <p> elements. A quick scan of the stylesheets also shows a template in footnote.xsl: <xsl:template match=""footnote/para[1]|footnote/simpara[1]" priority="2"> To avoid problems with footnote paras, you should probably add an apply-imports template for this one too. -- Bob Stayton 400 Encinal Street Publications Architect Santa Cruz, CA 95060 Technical Publications voice: (831) 427-7796 Caldera International, Inc. fax: (831) 429-1887 email: bobs@caldera.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC