Question on Transformer for Building OracleTransformer

[Steve Muench <sm...@us.oracle.com>]

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?    

_________________________________________________________
Steve Muench, Consulting Product Manager & XML Evangelist
Business Components for Java Development Team
http://technet.oracle.com/tech/java
http://technet.oracle.com/tech/xml

Re: Question on Transformer for Building OracleTransformer

[Stefano Mazzocchi <st...@apache.org>]

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?

yessir.

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.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Come to the first official Apache Software Foundation Conference!  
------------------------- http://ApacheCon.Com ---------------------