OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-apps message

[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