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: doctype and local subset in chunked (x)html outputfrom dbxsl

On Mon, Feb 04, 2002 at 01:16:08AM +0100, Steffen Maier wrote:
> On Thu, Jan 31, 2002 at 03:04:44PM -0800, Bob Stayton wrote:
> > On Thu, Jan 31, 2002 at 04:13:43PM +0100, Steffen Maier wrote:
> > > I'd like to know if it would be possible to agree on a change to the
> > > (x)html xslt stylesheets to allow easy customization of the chunked output
> > > prolog stuff like doctype or indenting?
> > > 
> > > While it is already customizable by overriding xsl:output for unchunked
> > > output, it is at present IMHO impossible for chunking.
> > >
> > > What I'm thinking of are parameters like $output.doctype-public,
> > > $output.doctype-system and $output.indent in addition to the already
> > > present $output.method. (Talking about docbook-xsl-1.48.)
> > > 
> <snip/>
> >
> > Interesting problem.  But I'm not sure I understand what
> > you are proposing for the extra parameters.  The
> > write.chunk.with.doctype template in chunker.xsl
> > already uses parameters for doctype-public, doctype-system,
> > and indent, they just aren't documented.  For example,
> > the exsl:document extension uses them:
> > 
> >       <exsl:document href="{$filename}"
> >                      method="{$method}"
> >                      encoding="{$encoding}"
> >                      indent="{$indent}"
> >                      doctype-public="{$doctype-public}"
> >                      doctype-system="{$doctype-system}">
> >         <xsl:copy-of select="$content"/>
> >       </exsl:document>
> Right, but aren't those parameters like $doctype-system local to the
> template, i.e. their scope is limited like for local variables, that are
> allocated on the stack, in other programming languages, e.g. automatic
> variables in C? That's what I understand from [REC-xslt-19991116, 11
> Variables and Parameters]. Then I couldn't specify them in my stylesheet
> driver to override the ones in the template, or am I wrong with that?

Yes, those parameters are all local, but they are meant
to be set when the template is called:

<xsl:template name="write.chunk.with.doctype">
  <xsl:param name="filename" select="''"/>
  <xsl:param name="method" select="$output.method"/>
  <xsl:param name="encoding" select="$default.encoding"/>
  <xsl:param name="indent" select="'no'"/>
  <xsl:param name="doctype-public" select="''"/>
  <xsl:param name="doctype-system" select="''"/>
  <xsl:param name="content" select="''"/>

So the trick is to pass the global parameters
to set the local parameters when the template is called.
> The parameters I proposed were meant to be in (x)html/param.xweb.
> Furthermore the write.chunk.with.doctype template is referenced nowhere
> within the stylesheets but only it's little brother write.chunk.
> The one...with.doctype is there for ... don't know, I guess
> Norm inserted it with great foresight ;-).
Now you have hit on the root of the problem.  It is pretty
hard to pass parameters to a template that never gets
called!  This does look like a good start that didn't get
finished.  Perhaps Norm can explain the current status of
this effort.

> If you take the stock (x)html/chunk.xsl from the 1.48 distribution you
> will only get a doctype declaration in your first/toplevel chunk but not
> in all the other chunks that are generated. I just don't understand yet
> why there is a declaration in the 1st chunk because I expected to be non
> at all. Maybe this comes from xsl:output, even with chunking?

That seems odd to me as well. The way I read the
stylesheet, even the root node can be a chunk and should
be handled by the document output extension element.  Does your
root node pass the test for being a chunk?

> The proposed diffs make use of these parameters and also of the mentioned
> template. But I see, that the changes are far from being correct; see
> below.

Not sure what part "below" you are refering to.

> > I don't think generating a literal '<DOCTYPE>' string
> > fits well with the XSLT processing model.  The DOCTYPE
> > declaration should be generated by the extension function
> > that writes each chunk, from parameters that are passed to
> > it.  
> I absolutely agree with that and I really hate to not conform to
> standards. But the fact that XSLT doesn't provide a solution leaves me
> kinda frustrated :-(. Maybe we could introduce a possibility for
> customization of the output before the root element. And leave the hack as
> a last resort when somebody really needs a local subset without having to
> post-process the chunks with sed or something else.
> > It looks like you can avoid outputting any DOCTYPE by not
> > specifying a doctype-system.  But the statement that
> OK, that means, it's not sufficient to have doctype-system's value be the
> empty string but the attribute itself must be omitted if we don't want a
> doctype declaration in the output. I guess this could be handled by a
> simple if statement testing the proposed $output.doctype-system and
> executing something with either the semantics of write.chunk or them of
> write.chunk.with.doctype.

I think that is right idea.
> > "The internal subset should be empty" is rather
> > definitive, even if it doesn't say why!
> Might be because the syntax for DTDs is not really XML although it is of
> course defined in the XML-REC... ?

Maybe the word "should" provides enough wiggle room
for an extension that outputs an internal subset.
After all, it doesn't say "must be empty".  8^)

Norm, if you could explain where you left off with
write.chunk.with.doctype, we could make some progress
with it.

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