cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kay Michael <Michael....@icl.com>
Subject RE: XSLT API Proposal (Draft 2)
Date Mon, 07 Feb 2000 10:46:37 GMT
You've all been busy over the weekend! I'll comment on the new class
definitions, rather than the discussion that led to them.

URIResolver: resolveURI should be passed the Base URI as well as the
specified URI

OutputProperties. This now looks quite similar to Saxon's OutputDetails
class, but it has some stuff which I don't really need or want: mine is much
more closely a direct mapping of the xsl:output properties. (I even keep the
values as yes/no strings rather than booleans, though I wouldn't defend that
strongly: it gives me the option to support additional values in a subclass,
e.g. the <saxon:output> extension elements now permits indent="3".) If this
is changed to be a pure data class with only those properties corresponding
directly to xsl:output I can live with it being a concrete class rather than
an interface.

SourceTree: I think it's right to separate this from XSLTInputSource. I'm
not too fussed about the API supporting "input from File", I can always do
it by changing my current ExtendedInputSource class to inherit from
XSLTInputSource instead of from InputSource.

XSLTExecContext. I hate the name. I have trouble with class names that are
quite so abstract, and I think users do too. I thought this class
represented a stylesheet after compilation, in which case I would have
called it CompiledStylesheet or ExecutableStylesheet. But the fact that
you're adamant that setParameter() belongs here, not to mention
createSourceTree(), makes me worry that I've understood it wrong. My model
is fairly simple: you start with a stylesheet expressed as a character
stream of some kind, you compile it (once) to create an executable
stylesheet, you can run this executable any number of times, in parallel if
you want, each time against a different source document and with different
parameters to create a different Result Tree. I'm having a little difficulty
relating this view of the world to some of the methods I see in
XSLTExecContext and Transform.

XSLTResultTarget. I'm having a little trouble with this one too. Again, my
model of the world is that the result of executing a stylesheet is a result
tree, and we need to tell the result tree what to do with itself. I do this
be supplying it with an Emitter, which is essentially an extended
DocumentHandler. Perhaps it would be closer to XSLT terminology to call it
an OutputMethod. Three of the Emitters available are HTMLEmitter,
XMLEmitter, and TextEmitter. The Emitter needs to know the properties
supplied to xsl:output, i.e. the OutputProperties. If it's going to
serialize the tree, it also needs to know a filename, character stream, or
bytestream to write to: in my model I therefore hold these properties in the
OutputDetails (=OutputProperties) object along with those specified to
xsl:output. Of course with multiple output files the output filename will
come from the stylesheet rather than from the API.

So I'm having trouble understanding the distribution of properties/methods
between XSLTResultTarget and OutputProperties (e.g. why is setEncoding() on
both); and I'd be a little inclined to try replacing XSLTResultTarget with
an OutputMethod class. 

Mike K 


Mime
View raw message