cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kay Michael <>
Subject RE: Proposal for Serializer API
Date Wed, 16 Feb 2000 15:34:17 GMT
1. I want to check that I understand the way you are using the word
"serialize". Your definition of "Serializer" in is
tautologous, it defines it merely as an interface to an implementation of
itself. Am I right in thinking that a serializer ALWAYS transforms a result
tree into a character or byte stream?

If so your concept of a Serializer is close to Saxon's concept of an
Emitter, but more restricted. I chose the name Emitter because not all
emitters do serialization. I think a serializer is one kind of emitter.
Another kind of emitter might be a GUI browser that allows the user to
browse around the result tree interactively; another might be one that does
a further transformation. What is true is that the three defined output
methods, and the OutputProperties, not to mention things like
setOutputByteStream(), are only relevant to emitters that produce serial

I think I'm saying that Serializer should extend an interface like Emitter,
and that the XSLT transform should be able to write to any kind of Emitter,
not only a serializer, and that asContentHandler() should be promoted to the
Emitter level.

Incidentally, we have exactly the same kind of duality on the input side,
where the current InputSource object is oriented to serial input and we need
to generalize it. [I'm toying with "Absorber" as the counterpart to

I don't think we should support both DocumentHandler and ContentHandler: we
should go straight for SAX2. It's easy to supply a SAX2 ContentHandler that
proxies a SAX1 DocumentHandler.

The setX() methods in Serializer should have corresponding getX() methods.

2. Having just looked again at DOMSerializer I realize I haven't the
faintest idea what it does, again all that the comment tells me is that it
is an interface to an implementation of itself. I assumed from the name that
a DOMSerializer was a kind of Serializer, but looking more carefully I see
that I was wrong. I'd encourage you to do what Scott did: provide some use
cases to help us understand what role each of the objects plays.

3. Regarding OutputFormat, I'm still unhappy that this API extends the scope
of what <xsl:output> can do. It should be extensible, so vendors or users
can define additional properties, but it should not include extensions in
its core definition. I think it would also be better in the long run to
separate interface from implementation: even though the class contains no
logic, there is scope for alternative implementations. For example, I might
want to implement it as a wrapper around the object representing the
<xsl:output> element. But there should be a "helper" implementation
available, pace SAX AttributeListImpl.

As a minor point, I would prefer having addCdataElement(QName element)
rather than setCdataElements(Qname[] elements). This is because they arrive
incrementally, one or more from each <xsl:output> element. Perhaps both
methods are needed, so there is a reset capability.

The 3-argument constructor seems totally arbitrary, I don't think this
combination of 3 attributes is likely to be any more common than any other
arbitrary combination. And setDocType() should be split into setSystemId()
and setPublicId().

4. QName similarly should be an interface. I want to wrap the Name objects I
already hold, which use a more economical representation than this, rather
than copying them. Is there no existing interface (e.g. in DOM2) that we can

5. I'm not an enormous fan of factory classes, but I'll live with it.
Another use case please: how do you propose that an XSLT user should ask for
output to be directed to a ContentHandler of his own making? How would
something like:

<saxon:output file="{$file}.html" method="com.user.MyFancyEmitter"/>

Mike Kay

View raw message