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] | [List Home]

Subject: Re: [docbook-apps] XHTML and Olink Database Generation Problems

For the record, I followed up on the problem of a DOCTYPE being generated in the output by Saxon when using the xhtml stylesheet. I had run into this problem before with the target.db file, the same problem that Ray encountered.
The problem is that when the main stylesheet has an <xsl:output> with doctype attributes (as xhtml/docbook.xsl does), there is no way to completely turn off that DOCTYPE when using the saxon:output extension that the Saxon processor uses to write out a file.  The following query that I posted to the Mulberry XSL-List last October summarizes the problem. Michael Kay (author of Saxon, no less) said in his response that there was no solution to the problem of inheriting the xsl:output settings or resetting it to nothing.
The DocBook chunking stylesheet has two parameters that should turn off the DOCTYPE:
<xsl:param name="chunker.output.doctype-public" select="''"/>
<xsl:param name="chunker.output.doctype-system" select="''"/>
This *almost* works.  That is, the chunked output files do not have a DOCTYPE declaration, with two exceptions: the top level index.html file, and the target.db file, both of which have the DOCTYPE in their output. 
I traced through the template processing with Oxygen's debugger, and at the point where saxon:output is called, it is given the same attribute values for its options as for all the other chunks that don't get a DOCTYPE.  None of the calls specify a doctype, yet in two cases a doctype is output anyway because Saxon inherits it from the main docbook.xsl stylesheet file.  In other words, the same call to saxon:output produces different results depending on whether or not write.chunk is called recursively. The calls to write.chunk for index.html and target.db are not nested within a recursive call, but all other calls (that don't output DOCTYPE) are.  That's the part that just seems strange to me.
The workaround for olinking is to accept the fact that target.db will have a DOCTYPE declaration when using the xhtml stylesheet and Saxon, and to use XInclude instead of entity references in your olink database that pulls in target.db.  You have to configure Saxon for XInclude processing, but it works.
If you absolutely must not have a DOCTYPE in your index.html or target.db, then you have two choices:
1.  Use xsltproc instead of Saxon.
2.  Copy xhtml/docbook.xsl to xhtml/mydocbook.xsl and edit out the doctype attributes in its xsl:output element.  That way Saxon has nothing to inherit. Then import mydocbook.xsl in your customization instead of the original.
Bob Stayton
Sagehill Enterprises
DocBook Consulting
----- Original Message -----
Sent: Thursday, February 15, 2007 9:16 AM
Subject: [docbook-apps] XHTML and Olink Database Generation Problems

docbook-rnc-5.0.CR1 xsl-1.72.0 oxygen-8.1 (eclipse-3.2.1 plugin)


When transforming to xhtml (../xhtml/profile-chunk.xsl) the following generated olink database code fragment does not validate, subsequently breaking all olinks in the transformation:



  PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<div element="article" href="index.html" number="" targetptr="fooInternet">


      <span xmlns="http://www.w3.org/1999/xhtml">Introduction</span>



      <span xmlns="http://www.w3.org/1999/xhtml">Introduction</span>


   <div element="sect1" href="background.html" number="" targetptr="background">



This issue does not arise with html transformations (../html/profile-chunk.xsl)




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]