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 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.)
> > 
> 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?

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 ;-).

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?

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

> 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

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



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

Powered by eList eXpress LLC