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.

 

http://www.biglist.com/lists/xsl-list/archives/200610/msg00021.html

 

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 ----- 

  
From: 
  Miller, Ray 
  (Centech) 

  
To:  
  

  
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:

  
 

  
<!DOCTYPE 
  div

  
  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">

  
  
   <ttl>

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

  
   
  </ttl>

  
   
  <xreftext>

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

  
   
  </xreftext>

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

  
        
  <ttl>Background</ttl>

  
…

  
…

  
 

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

  
 

  
Ray