cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: SAT API Proposal (Draft 3) (was XSLT API)
Date Thu, 10 Feb 2000 12:10:33 GMT
Scott Boag/CAM/Lotus wrote:
> 
> I've done some radical things to the API formarly known as the "XSLT API".
> I've come to the conclusion that this does not need to be, and should not
> be, an XSLT API!  Rather, it should be a Transformation API.  Therefore I
> am proposing renaming it to be the "Simple API for Transformations" (SAT
> for now) in the potential siblingship with SAX, contengent, of course, on
> Dave and who ever's in control on the org.xml space.

+1 for the idea, but what about "SAXT" (Simple API for XML
tranformations)... transformations are _way_ too general (gif to jpg,
dvi to postscript, etc...) we should restrict ourselves in the XML
domain, plus, avoid names like TAX which carry some negative meaning :)
think about the jokes with the TAX API and Microsoft... nah, we don't
want to trigger that...
 
> (Dave, I have been proposing a design for the past week that would define a
> standard interface in Java for XSLT processors, that would be vendor
> neutral).

It would make perfect sense (at least to me), to come up with a
transformation equivalent of SAX. Meaning that you use SAX if you don't
care about transformations, but use SAXT (which generally OO speaking
would extend SAX), which gives more details/control on the
transformation process.
 
> I decided to use SAX2's (http://www.megginson.com/SAX/SAX2/) ContentHandler
> and XMLReader interfaces, instead of SAX1's DocumentHandler and Parser,
> which are depricated.  If the future is SAX2, this interface should just
> use those and be done with it.  SAX1 can still be supported via some of
> SAX2's helper classes, I think.  There's a fair number of methods that have
> been ripped directly out of SAX.  This is in the spirit of trying to
> provide a consistent interface with SAX.  Dave, if you are offended for
> some reason, I'll rip them right out.

I welcome this. As I told David privately, I love SAX2... and both
Xerces 1.2 and Cocoon2 will be based on SAX2... I see no problems on
that.
 
> Making this a general Transformation API makes APIs for XML Serialization
> logical to include in this package. 

Totally.

> Therefore I have integrated in several
> of Assaf Arkin's Serializer interfaces.  I pretty much just tossed them in
> there, so some thinking will have to be done about the integration and
> details.  In general, I think the serialization interfaces need to be
> simplified a bit.

Ok. I agree with Mike that we should make this a wrapper for xsl:output
and provide any extention via properties or whatever else.
 
> I did a pretty radical renaming of the objects based on the discussions in
> the past days.  I think we should stick to Stylesheet instead of
> Transformation for the stylesheet object, because it is in such common
> usage, and letting us us that for the non-mutable bag of bits that is the
> transformation instructions, let's us use "Transformation" for the
> transformation context. 

Ok, I didn't jump in before because I wanted to see where you guys were
going. Here are my proposals:

 - Transformation = the context of doing the transformation
 - TransformationSheet = what contains the instructions for the
transformer
 - Transformer = what does the transformation

of course,

 - Transformer is a SAX2 filter

> I am calling the object that creates stylesheets
> the "Processor", again because it is in such common usage.

Well, sounds pretty nonsense to call it "transformation API" and then
have "Stylesheet" and "Processor". I agree that TransformationSheet is
not that nice and it's probably a neologism (I always make them), but
I've used this extensively in my mails and documents and never had
problems with that (we also have "LogicSheets" and so on).

Anyway I'm wide open to suggestions.

> I added a
> vendor neutral factory method on the Processor object that is modeled after
> Sun's parser factory interfaces.

Cool.
 
> I've made the Transformation object derive from SAX2 XMLFilter/XMLReader.
> This means that you can treate the transformation object as a parser!
> Sounds a little weard at first (James Clark suggested doing this for Parser
> several months back), but it seems to work out pretty well, at least from
> the standpoint of the interface.  One could argue that
> setDTDHandler/getDTDHandler is a little strange, but, then again, if you
> think about it, maybe not so strange.

Ok, since all the API for XML gurus are around here, I would like to
make some comments on XMLFilter and company:

There are two ways of dealing with events: push and pull.

If your logic is what "consumes" these events, you normally follow a
"pull/push" logic, which means: "I don't care what happens, but when I
say so, somebody will call my methods, feeding me with the proper data".

In such a situation, seeing the Transfomer as a Parser makes perfect
sense: in fact, the application may not care if this cames from the file
or comes from a file + transformations applied.

On the other hand, your logic may reside on the complete other side (as
Cocoon does!) and this requires a different way of thinking: "I give you
the handler of your data, when I say so, spits your data to it".

This is a "push/push" model. Nobody is ever asking for anything. Total
inversion of control. Much easier to code once you understood the
principle.

This is, IMO, how a pipeline should be created. XMLFilter is just a way
to wrap a parser, but I think this is a lot less useful than creating a
way to "pipe" filters one into the other and then trigger the execution.

Let's consider the general design patterns:

 SAX events can be either
   - produced
   - comsumed

A parser is an event producer. A filter is both producer and consumer. A
serializer is only a consumer.

Generally speaking, an XSLT processor is always a filter. In fact, even
if what comes out is not well-formed XML, SAX events can be used to
"transport" even plain text.

To the serializer is passed both the stream of SAX events and a
OutputFormat object that will drive the serialization process.

So, IMO, XMLFilter should be an extention of ContentHandler instead of
an extention of XMLReader.

Why?

Well, such a filter would then behave exactly like a producer with no
way (for people) to produce it's own SAX events and use the filter
without parsing.

So, I think the problem with SAX is that is _too_much_ parser-oriented,
or, more generally, "consuming-oriented".

SAX + SAXT could allow applications to use SAX as transport between some
internal logic for XML production and some logic for XML consuming. Then
it should provide "general" adapters stream->SAX (parser) and
SAX->stream (serializer) and SAX->SAX (XSLT) but these must be
considered general things... the API should be more abstract.
 
I'll wait for your comments on this general things instead of going into
the API details.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Come to the first official Apache Software Foundation Conference!  
------------------------- http://ApacheCon.Com ---------------------


Mime
View raw message