cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Proposal for Serializer API
Date Wed, 16 Feb 2000 22:49:24 GMT
Kay Michael wrote:
> 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
> output.

I've see your "emitter" pattern and I think it fits perfectly with the
idea of "production", as for the Gamma "producer/comsumer" pattern.

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

I disagree. A serializer is a "consumer" of XML events, and "producer"
of streams. But a stream producer is way to general to make it a
pattern. When choosing the serialization names, Scott, James Tauber and
myself came out with a good list of patterns... Scott, do you still have
it around?

Anyway, I think that "emitter" is a bad name since an XML-based API
should be xml-oriented... thus a serializer is an "absorber" of xml
events... well, for your GUI example, what are you emitting? pixels?
then everything is an emitter.
> 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
> "Emitter"...]

yes, producer/consumer. But while a parser is a producer, a serializer
is a consumer. Of XML events.
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche
 Come to the first official Apache Software Foundation Conference!  
------------------------- http://ApacheCon.Com ---------------------

View raw message