Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (asf.osuosl.org: domain of ap-cocoon-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
To: dev@cocoon.apache.org
From: BURGHARD =?ISO-8859-15?Q?=C9ric?= <eric.burghard@systheo.com>
Subject: Re: Suggestion for XHTMLSerializer
Date: Sat, 06 Aug 2005 18:45:52 +0200
Lines: 54
Message-ID: <dd2pdg$tcm$1@sea.gmane.org>
References: <b677085305080202252fb491ff@mail.gmail.com>
 <1123067609.7378.9.camel@localhost.localdomain> <dcvjmk$j9v$1@sea.gmane.org>
 <42F3AC2F.4080307@gmx.de> <dd1uab$7o0$1@sea.gmane.org>
 <42F48BAF.3010808@gmx.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7Bit
User-Agent: KNode/0.9.1
Sender: news <news@sea.gmane.org>

> 1. I was talking about the concept, not implementation details. And from
> that POV a stylesheet should not influence the pipeline. IMO It's plain
> wrong to set the output format in the stylesheet.
>
> 2. But yes, I was missing the most important point in your approach
> thinking that any stylesheet in the pipeline can have influence on it.
> If you encapsulate the stylesheet in the serializer like it is done now
> as you wrote there is no problem with it. But from what I understand you
> want to provide "public access" to it, meaning that anybody can change
> the stylesheet to adapt the output. Here the approach gets wrong again -
> how will you prevent doing more stuff in the stylesheet than just
> serialization with some cleaning up? It is made to easy ... The standard
> tasks like "getting rid of alien namespaces" can be encapsulated. You
> should not provide any access to the stylesheet. And then it should not
> be called XSLSerializer, but something like
> MoreSophisticatedXMLSerializer - however you will call it.
>

I certainly miss something, but i don't see the point. I don't see how this
could be used to break the actual pipeline design. With the XSLSerializer i
write

<match pattern="...">
 <generate src="..."/>
 <serialize type="xsl" src="serialize/xhtml.xsl"/>
</match>

I know this is a serialization, and i know that the serialization is
controlled by the xslt processor. As a pipeline architect i know that it
should serialize to xhtml, and as an xsl programmer i know where to look to
find the implementation details. I don't have to be a java programmer, and
absorb all that sax stuff and avalon life cycle to make my own serializer
which do some really complicated stuff efficiently like entities
replacement (with xslt2.0).

You cannot prevent someone to do more complicated stuff (that just removing
ns) with this serializer, as you can cannot prevent someone to do bad and
complicated things with a pure java serializer, but with the former at
least i cannot produce a corrupted sax flow, which is better i think. So as
an hardcore designer, i could even say that it's better to remove all the
java serializers and keep only the xsl one, but as an open source
enthousiast i will just say, please accept this poor litle xsl serializer
in the cocoon family :-).

As a beginner with cocoon, i was always disapointed when i put <xsl:output
indent='yes'/> in my stylesheet, and saw that the result was not indented
at all. Now that i know a little more on pipeline design, i really think
that the xslserializer could make all the experienced xslt programmers much
more comfortable with the serialization process in cocoon.

It's not a virtual serializer, it's a full serializer component that can
only be used as a serializer in a virtual serializer.

Regards.