cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Question on Transformer for Building OracleTransformer
Date Mon, 10 Jan 2000 22:23:56 GMT
Steve Muench wrote:
> Stefano, et al,
> I'm trying to build you guys a OracleTransformer
> and OracleParser implementation to plug back into
> Cocoon 1.6 or beyond.
> One question I have is that the interface for
> Transformer passes me in an empty Document
> to use for appending the transformed result
> tree DocumentFragment. I don't see how a
> processor which supports <xsl:output> gets
> a chance to write out it's method="HTML" output
> if done this way.
> For example, if you give our XSLT engine
> a stylesheet that says:
> <xsl:output method="html"/>
> Then if you give us an OutputStream or a PrintWriter
> we'll write the proper HTML-formatted tags out,
> so that <br/> turns into <br> among other little
> tweaks. If you use our API that returns a DocumentFragment
> we cannot do this for you obviously.
> So my question is, in Cocoon, is the intent
> that the <xsl:output> in a particular stylesheet
> get ignored by the XSLT processor and then
> the FormatterFactory decides later what serialization
> to use?


This is part of the sitemap idea: you should not place anything inside
the XSLT files that drives the processing directly.

True, the XSLT specification doesn't distinguish between processors and
formatters, but, IMO, this is a design mistake.

The very first line of the spec says that XSLT is a file to transform
XML documents into XML documents. Well, <xsl:output> breaks this. So,
since the spec allows you not to consider it, this is what we do (unless
someone comes up with strong opinions about it and valid points).

Anyway, if you really think about it, <xsl:output> is the equivalent of
<?xml-stylesheet?>. An hard link between two different contexts. As the
sitemap proposal shows, it's much easier to manage a site when there are
no hard links between contexts, but only "soft" links that can easily
modified in a single place.

For example, consider <xsl:output type="syntax-highlighted-on-pdf"/>
which prints a syntax highlighted tree-like version of the generated XML
file, or <xsl:output type="VRML-rendered-on-jpg"/> or <xsl:output
type="voiceml-rendered-on-wav"/>... you name it.

The only significant problem is that you must encapsulate XSLT-produced
text with at least some fake tags, or Xerces DOM will throw an error.
(this is what the VRMLFormatter does today).

Not really clean, but will be fixed with SAX support.

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