cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Assaf Arkin <>
Subject Re: Proposal for Serializer API
Date Wed, 16 Feb 2000 19:10:01 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.

"Serializer" is simply the common terminology suggested by a group of
people, and also adopted by the W3C. Emitter, formatter, printer,
output, etc were also suggested. Serializer seemed to convey the pattern

> 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

I don't think so. A GUI browser using the DOM might want to update the
DOM, or it might want to keep it alive after the serialize() method
returns (the caller can destroy the DOM afterwards).

It's a different design pattern, and it doens't call for
OutputFormat/Method, etc.

> a further transformation. What is true is that the three defined output

Further transformation is supported, but if you want to control it, you
better use a processor. Not necessarly XSLT, but I believe the XSLT API
should allow you to use a non-XSLT processor as well.

> methods, and the OutputProperties, not to mention things like
> setOutputByteStream(), are only relevant to emitters that produce serial
> output.
> 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.

XSLT transform writes to a DOM, DocumentHandler or ContentHandler.

A Serializer merely supplies an implementation to these interfaces for
the purpose of serialization.

An XSLT transformer need not accept a Serializer directly, a Serializer
by itself is not a ResultTarget.

Not that there is any problem with that, but I think that binding XSLT
transformation output into Serializers will cause developers to think
about the available tools, not all the possible uses of them.

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

That's a possibility. I'm only doing SAX2, but I do believe there are a
lot of people out there that will be doing SAX1 for a while. A
serializer can always provide the suitable adapter.

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

Why? As I explained, Serializer represents an implementation of a
serializer, not a result target.

I think what you imply is that we should come up with a ResultTarget
(set/get output stream), which a Serializer or Transformer can accept.

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

  SerializerFactory factory = new MySerializers();

  Serializer ser;

  ser = factory.getSerializer( Method.XML );
  ser.setOutputStream( System.out );

  ser.asDOMSerializer().serializer( doc );


  parser.setDocumentHandler( ser.asDocumentHandler() );

> 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

It doesn't. I took away all the extra implementation stuff (like the
witch methods) and left on the xsl:output properties.

> 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

+1 That is my intention as well.

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

On the one hand you want a simple interface, and on the other hand you
want it to be a bit smarter :-)

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

I accept both arguments. The 3-argument constructor was based on what I
saw people use it most outside of XSLT (i.e. plain serialization). But I
agree it's arbitrary. I also agree on setDocType().

> 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
> use?

We get too many interfaces and not enough implementations.

What happens is that your implementation (or mine, for that matter) are
smaller, but the end-user application becomes larger with factories,
helper classes, importing an interface+class each time, etc.

Considering that the ratio between applications and implementations is
more than 1:10 I tend to favor more classes, less interfaces.

> 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"/>
> work?

You will have to construct an instance of com.user.MyFancyEmitter that
implements Serializer, and pass it a SaxonOutputFormat. saxon:output
would include additional properties that will map into SaxonOutputFormat
and the serializer can take care of them.

So factory class:

  public void getSerializer( String method )
    return Class.forName( method ).newInstance();

followed by

  ser.setOutputFormat( saxonOF );
  ser.setOutputStream( new FileOutputStream( file ) );
  ch = ser.asContentHandler();


> Mike Kay

Assaf Arkin                                 
CTO, Exoffice Technologies, Inc.              

View raw message