[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