You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Antonio Fiol Bonnín <an...@gmail.com> on 2005/08/02 11:25:52 UTC
Suggestion for XHTMLSerializer
Hello,
I am finding a problem with empty elements when serving content with the
text/html content type on Firefox. For example, collapsed empty div elements
cause havoc in firefox. A possible workaround would be implementing the
compatibility guidelines indicated in the W3C recommendations.
In particular, I would add the same check already present for style, script
and textarea for any element whose end tag is required in HTML 4.01.
Would a patch for this be welcome?
Yours,
--
Antonio
RE: Suggestion for XHTMLSerializer
Posted by BURGHARD Éric <er...@systheo.com>.
Kees Broenink wrote:
> Éric,
>
> I tried your solution described below but it does not solve the
> <script></script> problem...
>
> <script type="text/javascript" src="/bxs/3_0_1/bpc/boot.js"></script>
>
> will return:
>
> <script type="text/javascript" src="/bxs/3_0_1/bpc/boot.js"
> xml:space="preserve" />
>
> So IE is not happy.
>
> Regards, Kees
it works with saxon8 with html and xhtml methods.
You can test other processor with a XSLT1.0 version of this stylesheet
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns="http://www.w3.org/1999/xhtml"
xpath-default-namespace="http://www.w3.org/1999/xhtml"
version="2.0">
<xsl:output method="xhtml"/>
<xsl:template match="*|@*|text()">
<xsl:copy>
<xsl:apply-templates select="*|@*|text()"/>
</xsl:copy>
</xsl:template>
</xsl:stylesheet>
on this data
<?xml version="1.0" encoding="UTF-8"?>
<test>
<script/>
<div/>
<inputarea/>
<br/>
</test>
With saxon8, script, div, and inputarea are reopened, but br is serialized
"as is".
Regards.
Re: Suggestion for XHTMLSerializer
Posted by BURGHARD Éric <er...@systheo.com>.
BURGHARD Éric wrote:
>> What XMLSerializer are you talking about? The one in the serializers
>> block or the default one?
>>
>
umh, i went to quickly :-), this is
org.apache.cocoon.serialization.XMLSerializer
Re: Suggestion for XHTMLSerializer
Posted by Joerg Heinicke <jo...@gmx.de>.
On 07.08.2005 01:27, Jason Johnston wrote:
> But the important thing is that using an XSLT internally is merely an
> implementation detail. Exposing the XSLT implementation to users is
> what Joerg and I take issue with. (Don't mean to speak for you here,
> Joerg, correct me if I'm misquoting you.)
Both your mails address exactly my concerns. I could not have them
written better ;-)
Joerg
Re: Suggestion for XHTMLSerializer
Posted by BURGHARD Éric <er...@systheo.com>.
> Why not collapse the entire pipeline into a single component as well, that
> would eliminate a massive amount of bugs and testing time of the Sitemap
> ;o)
>
It's a brillant idea, but it's yours :-D
> Componentization with semantically well-defined contracts in between, is a
> far better than large monoliths with innumerous permutations of
And who is talking about large monoliths now ;-) ?
> configuration, rules/exceptions, outcomes, side-effects and associated
> subtleties. Do one thing, and do it damn well. That is what we like about
> Cocoon... Adult Lego!
>
That's what i like in cocoon too.
> Virtualization of a pack of transformers, with optional Generator and
> Serializer seems like doing the job more elegantly. At least as much as I
> have understood reading this all.
>
I use virtual generator with an xmldb generator and some bunch of
transformers on my project to simplify some common pipelines. I found that
effectively usefull and elegant, but xslserialisation is not directly
related to virtualisation, even if you could stack (i know that you will
appreciate that as a componentizator :-) some transformers with an
xslserializer.
Regards
Re: Suggestion for XHTMLSerializer
Posted by Niclas Hedhman <he...@gmail.com>.
On Sunday 07 August 2005 20:51, BURGHARD Éric wrote:
> He was just wondering if this thread was about virtual serialization. It's
> not.
What IS it about??
> XSLSerializer is a full featured serializer which can play the role of
> a serializer in a virtual serializer if you really want to virtualize, but
> what's the use of this extra step if i could do it in one, without bugs and
> without breaking any pattern design ?
Why not collapse the entire pipeline into a single component as well, that
would eliminate a massive amount of bugs and testing time of the Sitemap ;o)
Componentization with semantically well-defined contracts in between, is a far
better than large monoliths with innumerous permutations of configuration,
rules/exceptions, outcomes, side-effects and associated subtleties. Do one
thing, and do it damn well. That is what we like about Cocoon... Adult Lego!
Virtualization of a pack of transformers, with optional Generator and
Serializer seems like doing the job more elegantly. At least as much as I
have understood reading this all.
Cheers
Niclas
Re: Suggestion for XHTMLSerializer
Posted by BURGHARD Éric <er...@systheo.com>.
Niclas Hedhman wrote:
> On Monday 08 August 2005 01:22, BURGHARD Éric wrote:
>
>> standard serializers are bugged.
>
> If we have bugs in the serializers, then let's address it.
> If we need more "types" of serializers, then we address that.
>
Read my answer to antonio, it will perhaps be more clear. XSLProcessor is
actually limited to the transformer role despite the fact it's a real
serializer outside cocoon (take a look at the spec: 20.serialization).
> Eric, I think the only thing that people get "hung up on" is the
> suggestion that there would come into existence a "fat" serializer where
> the output can not be determined by examining the input and its
> parameters, and that effectively a Turing-machine is sitting inside.
>
I would hang up on such a suggestion too. Can't you predict the effect of
<serialize type="xsl" src="xhtml.xsl"/> ? I think that a turing-machine is
sitting inside every component logic no ?
> But if you feel this serializer is necessary to get the work done, please
> be everyone's guest, make it, promote it and show all us non-enlightened
> of its beauty... ;o)
>
You enlighten me by pointing me so well to the right direction and forcing
me to reformulate my sentence and fine tune my poor english :-)
Regards.
Re: Suggestion for XHTMLSerializer
Posted by Niclas Hedhman <he...@gmail.com>.
On Monday 08 August 2005 01:22, BURGHARD Éric wrote:
> standard serializers are bugged.
If we have bugs in the serializers, then let's address it.
If we need more "types" of serializers, then we address that.
Eric, I think the only thing that people get "hung up on" is the suggestion
that there would come into existence a "fat" serializer where the output can
not be determined by examining the input and its parameters, and that
effectively a Turing-machine is sitting inside.
But if you feel this serializer is necessary to get the work done, please be
everyone's guest, make it, promote it and show all us non-enlightened of its
beauty... ;o)
Cheers
Niclas
Re: Suggestion for XHTMLSerializer
Posted by Sylvain Wallez <sy...@apache.org>.
Vadim Gritsenko wrote:
> Joerg Heinicke wrote:
>
>> On 07.08.2005 19:22, BURGHARD Éric wrote:
>>
>>> Completely wrong. If you find a 1:1 relation between a svg and a
>>> bitmap, go
>>> ahead man, you're rich. For me a svg serialization is not
>>> reversible, you
>>> loose layers, labels, structure and of course scalability.
>>
>>
>> Man, 1:1 does not mean that you can go in both directions!
>
>
> Joerg,
>
> You just proved Eric's point. Moreover, I don't see why go all
> religious on simple and (as it seems) useful idea of XSLSerializer. We
> do have FOP, Batik, etc serializers - why not Trax.
Yep. And this could allow for a smart serializer that detects if the
user agent is XSL aware and, depending on that, decides between
client-side and server-side transformation. This was discussed 2 months
ago: http://marc.theaimsgroup.com/?t=111928428500001&r=1&w=2
> If you want crusades or jihad (take your pick), start with
> XSLGenerator which is already in the trunk for 2 years, 3 months ago :-)
:-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Suggestion for XHTMLSerializer
Posted by Joerg Heinicke <jo...@gmx.de>.
On 09.08.2005 02:17, Vadim Gritsenko wrote:
>> From the pipeline's POV it's not 1:1 as the serializer decides to
>> which output format the XML is serialized, so it is 1:n, so the output
>> is also not predictable for the pipeline.
>
> Output of the serializer is never predictable, otherwise no need for
>
> /**
> * Get the mime-type of the output of this <code>Component</code>.
> */
> String getMimeType();
1. This does not change the content, only the headers.
2. It's configured in the sitemap or even hard-coded in the serializer -
and so nothing with dynamic access. Or is there any serializer
determining this option dynamically?
>> But IMO the codebase is already to big. There are so many components
>> based on problematic approaches (SourceWritingTransformer,
>
> What would be the migration path? (beside flow).
I don't want to replace every "problematic" component that I don't like.
I just don't use them.
>> DOMSessionTransformer (both with side effects))
>
> You mean WriteDOMSessionTransformer? Should be deprecated, imho. Could
> be replaced with SourceWritingTransformer and dom source, or some such.
Yes, and it's pendant the ReadDOMSessionTransformer. About replacing it:
We talked about it since the contribution of the XModule source by
Daniel: http://wiki.apache.org/cocoon/XModuleSource.
But we leave the original topic here.
>> or widely unused (why is the TraxGenerator still in trunk after more
>> than 2 years?).
>
> <shrug> Some of the code is 5 or 6 years old. So what? </shrug>
>
> It's in the scratchpad.
That was what I meant. It's in the scratchpad for more than two years.
Joerg
Re: Suggestion for XHTMLSerializer
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Joerg Heinicke wrote:
> On 08.08.2005 23:10, Vadim Gritsenko wrote:
>
>> XSLT serialization (as per spec Eric quoted) provides a way for "one
>> way 1:1 transformation" of xml into the desired view format exactly in
>> the same way as batik transforms svg into png. XSLT has more
>> capabilities, one even might say that it allows for arbitrary xml
>> transformations - but another will say that's exactly the
>> transformation he needs for his view.
>
> From the pipeline's POV it's not 1:1 as the serializer decides to which
> output format the XML is serialized, so it is 1:n, so the output is also
> not predictable for the pipeline.
Output of the serializer is never predictable, otherwise no need for
/**
* Get the mime-type of the output of this <code>Component</code>.
*/
String getMimeType();
>> TraxSerializer does not force you to put your final view xslt
>> transform into the serializer. And I'd even discourage you to do it -
>> as it, in some scenarios, reduces possibilities of reuse - but in some
>> scenarios it'd be advantageous to add small xslt based serialization
>> instead of writing yet another java serializer.
>
>
> Yes, I'm not forced to use TraxSerializer. Maybe I should withdraw from
> this discussion because it leads to nearly nowhere. Let's just add this
> component to Cocoon's codebase.
>
> But IMO the codebase is already to big. There are so many components
> based on problematic approaches (SourceWritingTransformer,
What would be the migration path? (beside flow).
> DOMSessionTransformer (both with side effects))
You mean WriteDOMSessionTransformer? Should be deprecated, imho. Could be
replaced with SourceWritingTransformer and dom source, or some such.
And, just to make it clear, "side effects transformers" are not problematic.
They are not a best practice, so we don't generally recommend them, but it does
not mean they have no place. And some of such transformers have no replacement
at all.
> or widely unused (why is
> the TraxGenerator still in trunk after more than 2 years?).
<shrug> Some of the code is 5 or 6 years old. So what? </shrug>
It's in the scratchpad. Combined with TraxSerializer, they both can be part of
trax block.
> Why shall we
> add another component that's problematic (at least in my POV, see above)?
It does not have to be in the trunk (options - own block, wiki, bugzilla, sf,
external block). It does not have to be even added - but I don't see why not.
Vadim
Re: Suggestion for XHTMLSerializer
Posted by Joerg Heinicke <jo...@gmx.de>.
On 08.08.2005 23:10, Vadim Gritsenko wrote:
> XSLT serialization (as per spec Eric quoted) provides a way for "one way
> 1:1 transformation" of xml into the desired view format exactly in the
> same way as batik transforms svg into png. XSLT has more capabilities,
> one even might say that it allows for arbitrary xml transformations -
> but another will say that's exactly the transformation he needs for his
> view.
From the pipeline's POV it's not 1:1 as the serializer decides to which
output format the XML is serialized, so it is 1:n, so the output is also
not predictable for the pipeline.
> TraxSerializer does not force you to put your final view xslt transform
> into the serializer. And I'd even discourage you to do it - as it, in
> some scenarios, reduces possibilities of reuse - but in some scenarios
> it'd be advantageous to add small xslt based serialization instead of
> writing yet another java serializer.
Yes, I'm not forced to use TraxSerializer. Maybe I should withdraw from
this discussion because it leads to nearly nowhere. Let's just add this
component to Cocoon's codebase.
But IMO the codebase is already to big. There are so many components
based on problematic approaches (SourceWritingTransformer,
DOMSessionTransformer (both with side effects)) or widely unused (why is
the TraxGenerator still in trunk after more than 2 years?). Why shall we
add another component that's problematic (at least in my POV, see above)?
Joerg
Re: Suggestion for XHTMLSerializer
Posted by Joerg Heinicke <jo...@gmx.de>.
On 10.08.2005 01:44, Antonio Gallardo wrote:
> OK Guys, I am wondering if all the developers are following this very
> interesting thread.
The pure number of mails speaks for the importance of this thread ;-)
> I will suggest to start a new one and include in the
> title the "TraxTransformer" keyword.
No! Ok, if you need it, start a vote thread about adding TraxSerializer
to trunk/scratchpad. Otherwise just commit it.
Joerg
Re: Suggestion for XHTMLSerializer
Posted by Antonio Gallardo <ag...@agssa.net>.
Vadim Gritsenko wrote:
> Joerg Heinicke wrote:
>
>> I still don't see why we should add a component to the Cocoon
>> codebase, where we know from the beginning that it is "not best
>> practice" (better formulation than my "problematic", but meaning the
>> same).
>
>
> I'll rephrase what I wrote in one short sentence:
>
> Anything can be either used 'as recommended', or abused.
>
>
> I don't see how TraxSerializer is different. It can be used following
> 'best practice', or it can be abused (as was shown in the snipped
> part). It can be in the scratchpad forever and nobody will (ab)use it,
> or it can be documented with well defined 'best practices' and in wide
> use.
>
> It's not even much different from base Serializer interface - the
> major difference is that it provides another implementation language.
> Should we then ban JavaScript (Python, Ruby, etc) on the basis that it
> makes development too easy? Or may be we should use them but remember
> to apply 'best practices'?
OK Guys, I am wondering if all the developers are following this very
interesting thread. I will suggest to start a new one and include in the
title the "TraxTransformer" keyword.
Since, I am more practical than academic persons, I tend to agree that
the new proposed serializer is a good idea. It will improve performance
in some places and to me this is welcomed. Call me "crazy guy", because
for me every nanosecond counts! ;-)
But, I will like to hear more opinions about this. :-)
WDYT?
Best Regards,
Antonio Gallardo.
Re: Suggestion for XHTMLSerializer
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Joerg Heinicke wrote:
> I still don't see why we should add a component to the Cocoon codebase,
> where we know from the beginning that it is "not best practice" (better
> formulation than my "problematic", but meaning the same).
I'll rephrase what I wrote in one short sentence:
Anything can be either used 'as recommended', or abused.
I don't see how TraxSerializer is different. It can be used following 'best
practice', or it can be abused (as was shown in the snipped part). It can be in
the scratchpad forever and nobody will (ab)use it, or it can be documented with
well defined 'best practices' and in wide use.
It's not even much different from base Serializer interface - the major
difference is that it provides another implementation language. Should we then
ban JavaScript (Python, Ruby, etc) on the basis that it makes development too
easy? Or may be we should use them but remember to apply 'best practices'?
Vadim
Re: Suggestion for XHTMLSerializer
Posted by Joerg Heinicke <jo...@gmx.de>.
On 09.08.2005 02:03, Vadim Gritsenko wrote:
> * Serializers are allowed to implement SitemapModelComponent
> * SitemapModelComponent has setup method
> * setup() method passes src parameter - src attribute from the sitemap.
>
> Now, from Cocoon design perspective, this is all legal and supported.
...
>> That "well documented and understood option of the XSLT specification"
>> was categorically rejected when designing Cocoon 2.x.
>
> Can you send a link to that?
Having the serializers implementing SitemapModelComponent happened not
_that_ long ago:
http://thread.gmane.org/gmane.text.xml.cocoon.devel/26621. So there must
have been reasons to do not so before.
>> Wouldn't something like a TRAXSerializer add side effects to the
>> concept of sitemap serializers?
>
> What would be the side effects? It's harder to implement side effects in
> XSLT than in custom Java serializer.
But Java is harder to write than XSLT. Many design decisions in Cocoon
were made to heighten the barrier of abuse.
>> Introducing a trax serializer means that what you see in the sitemap
>> serializer declaration is only *part* of what is output. There is a
>> huge difference between the two, and I can see why Joerg was so upset.
>>
>> * The svg2jpeg serializer always requires SVG input and always
>> provides JPEG output -- including the mime type of image/jpeg.
>> * The fo2pdf serizalizer always requires XSL:FO input and always
>> provides PDF output -- including the mime type of application/pdf.
>
> FOPSerializer capable of producing PDF, PS, PCL, and (IIRC) more.
Capable yes, but not deciding dynamically. The pipeline knows the result
*before* the serializer has been executed, i.e. at setup time:
http://svn.apache.org/viewcvs.cgi/cocoon/blocks/fop/trunk/conf/fop.xmap?rev=179076&view=markup.
> That's good practice, which does not go away with adding new serializer.
...
> But I'd not call it best practice - as I mentioned previously.
...
> Having tools to do it does not mean you should do it. As they say,
> "Closed course, professional driver. Don't try it at home".
I still don't see why we should add a component to the Cocoon codebase,
where we know from the beginning that it is "not best practice" (better
formulation than my "problematic", but meaning the same).
Joerg
Re: Suggestion for XHTMLSerializer
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Roy G. Biv wrote:
> Forgive me for jumping in, but people seem to be talking past one
> another. I don't think you are talking about the same issue(s). Correct
> me if I'm wrong.
I'm just arguing here - you are in better position to see what we are arguing
about ;-)
<snip/>
> From Vadim and Eric: Many (most?) serializers are not reversible and
> therefore there should be no prohibition on yet another seemingly useful
> serializer based upon XSLT and its output element.
True.
> From Joerg: An XSLSerializer (or TRAXSerializer) would require a src
> attribute and so depend on something outside the sitemap for its
> behavior. This is a question of side effects.
Not a criminal offence. Three easy steps:
* Serializers are allowed to implement SitemapModelComponent
* SitemapModelComponent has setup method
* setup() method passes src parameter - src attribute from the sitemap.
Now, from Cocoon design perspective, this is all legal and supported. Question
might be about best practices, but that's different discussion.
<snip/>
>> TraxSerializer does not break above design in any single place. It
>> just gives you additional serialization option, which is,
>> coincidentally, explores well documented and understood option of the
>> XSLT specification, which is a plus in my book.
>
> That "well documented and understood option of the XSLT specification"
> was categorically rejected when designing Cocoon 2.x.
Can you send a link to that?
> It was obviously
> intended for standalone use just as processing instructions in XML to
> determine the XSLT or CSS stylesheet. It is fundamentally at odds with
> the Cocoon pipeline, as has been mentioned on the mailing list for years.
You can't use it in the transformer - true. It just does not make sense there.
>> TraxSerializer does not force you to put your final view xslt
>> transform into the serializer. And I'd even discourage you to do it -
>> as it, in some scenarios, reduces possibilities of reuse - but in some
>> scenarios it'd be advantageous to add small xslt based serialization
>> instead of writing yet another java serializer.
>
>
> Can you enumerate these scenarios?
IESerializer springs to mind ;-)
> What could you do for this that you
> cannot do with a trax transformer followed by one of the existing
> serializers? What advantage is there over, say, a virtual serializer
> made up of an xslt transform and a serializer?
Thinking about it, ... I don't want my resuling (pre-serializer) XML to be
polluted with implementation details/deficiencies of a particular browser
(pda/phone/whatever). I want it to stay the same so I can re-use (via cocoon:)
elsewhere.
> Now, to add some more fodder to this discussion... Are there any other
> serializers that rely on non-sitemap assets such as template files for
> operation?
Two answers:
* FOPSerializer takes xml config file.
* What presense or absense of the example proves? (Hint: nothing).
> Wouldn't something like a TRAXSerializer
> add side effects to the concept of sitemap serializers?
What would be the side effects? It's harder to implement side effects in XSLT
than in custom Java serializer.
> Currently the
> sitemap is as much a processing contract as it is a processor. By
> looking at the sitemap pipeline, you can see what should be read, what
> the schema/format is at each stage of the pipeline, and exactly what is
> sent out.
As long as you know what components are you using do. As soon as you discover
component not known to you, all bets are off.
> The svg2jpeg serializer is not 1:1 as Vadim and Eric have pointed out.
> They are not equal. However, this does not invalidate Joerg's point. It
> is a *completely different* point. A better, clearer statement is that
> serializers are not 1:1 (to be clear, nothing in Cocoon 2 is) but rather
> 1->1. There have been no end of emails equating reversibility (1:1) to a
> processing anti-pattern. Currently, what you see in the sitemap
> serializer declaration is what is output.
This is not correct, see below.
> Introducing a trax serializer
> means that what you see in the sitemap serializer declaration is only
> *part* of what is output. There is a huge difference between the two,
> and I can see why Joerg was so upset.
>
> * The svg2jpeg serializer always requires SVG input and always provides
> JPEG output -- including the mime type of image/jpeg.
> * The fo2pdf serizalizer always requires XSL:FO input and always
> provides PDF output -- including the mime type of application/pdf.
FOPSerializer capable of producing PDF, PS, PCL, and (IIRC) more.
> * A hypothetical trax serializer would require a specific input
> (elements that the stylesheet is expecting) but the output is...? HTML
> sometimes, generic XML other times, etc.?
>
> It can't do it now, but what if someone writes an SVG-to-raster output
> plugin to Xalan?
Why necessarily Xalan - it can be done in Java. Should we prohibit writing
serializers in Java, then? Don't think so.
> Would it be acceptable or clear to have HTML sometimes,
> generic XML other time, and a binary format still other times?
Yes. Quote:
/**
* Get the mime-type of the output of this <code>Component</code>.
*/
String getMimeType();
> Also, don't underestimate the value of having XSLT only in the middle of
> a pipeline. Why? The sitemap maintainer can look at a pipeline
> declaration and see that a stylesheet has specific input and specific
> output. How so?
>
> <!-- My input source may be variable, but the output must match the next
> link in the chain -->
> <map:generate src="myxml"/>
> <!-- The transformer must be written to the expected generator output. -->
> <map:transform src="schema1toSVG.xsl"/>
> <!-- The transformer must output the correct format, in this case SVG,
> or the serializer breaks.
> The serializer always expects SVG and always outputs JPEG. -->
> <map:serialize type="svg2jpeg"/>
>
> In that example, I can look at the sitemap and know exactly what's going
> on.
That's good practice, which does not go away with adding new serializer.
> Compare this to a TRAXSerializer example:
>
> <map:generate src="myxml"/>
> <!-- The generator output must be exact or the XSLT won't match elements
> correctly.
> The serializer must be written to the expected generator output. -->
> <map:serialize type="trax">
> <map:parameter name="xslt" value="stylesheet.xsl"/>
> </map:serialize>
>
> In the second example, I know what went in, but I have absolutely no
> idea what happens to it unless I as the sitemap maintainer also know
> XSLT as well. I am completely dependent upon the filename of the
> stylesheet for a functionality hint.
Yes, you should here apply the same practice you used above:
<map:serialize type="trax" src="schema1toxhtml.xsl"/>
But I'd not call it best practice - as I mentioned previously.
> It gets even more fun with stuff
> like the following:
>
> <map:serialize type="trax">
> <map:parameter name="xslt" value="cocoon:/stylesheet.xsl"/>
> </map:serialize>
>
> Let's take this to its logical conclusion. When would you ever want to
> have the output type be dynamically assigned by the serializer
> stylesheet?
When would you ever use something like this?
http://localhost:8888/samples/sources/xsp/all-dynamic
Having tools to do it does not mean you should do it. As they say, "Closed
course, professional driver. Don't try it at home".
> After all, this is the *only* reason for TRAXSerializer
> rather than an XMLSerializer with a specified doctype.
That usage scenario even never came into my mind. I wouldn't suggest it to
anybody, and will talk you out of using it (at least - I'd attempt to :-)
> What is the use
> case? If it's static and the stylesheet output type and mime/type never
> changes, the only thing you've gained is a sitemap that isn't as clear
> as to what was going on in the pipeline.
>
> Having the logic (XSLT stylesheet in this case) determine the processing
> -- specifically the output portion of the sitemap process -- sends us
> back to Cocoon 1.x, doesn't it? Is ProcessingInstructionTransformer far
> behind where the processing instruction in the source XML stream
> determines the stylesheet to use?
You missed it: it was proposed and discussed long time ago. Unfortunately ;-),
nobody needed the beast strong enough to actually come around and implement it.
The working name was "ReactorTransformer", or "C1Transformer".
Vadim
> Don't kid yourself. That's what we're
> talking about with a TRAXSerializer.
>
> I completely agree with Joerg.
>
>
> My $0.02,
>
> Miles Elam
Re: Suggestion for XHTMLSerializer
Posted by BURGHARD Éric <er...@systheo.com>.
> From Vadim and Eric: Many (most?) serializers are not reversible and
> therefore there should be no prohibition on yet another seemingly useful
> serializer based upon XSLT and its output element.
>
In fact, if i try to summarize this thread, we are just talking about
implementation language. From now java was the only language for writing
serializers. With a TraxSerializer (you're right vadim, this name would
have certainly avoid all this XSL crispation :-) you can write them in XSL.
A Trax Serializer, is much more isolated from object model than a java one,
so don't tell me that they could encourage abuses. You play with the sax
stream in a java serializer and trax one in the exactly same (it's just
simpler, and the risk of stream corruption is lower with xsl). For some
things you cannot just use existing serializer (characters-map).
Serialization in xsl 2.0 is feature rich, and it would be a pain and a
waste of time to reimplement them.
And if you can stand the src attribute on the serializer, just define a
virtual serializer in such a manner that
<map:serialize type="xsl" src="serialize/xhtml.xsl"/>
become
<map:serialize type="clean-xhtml"/>
in your pipelines.
We use a traxserializer on our project since 2 months (as sylvain pointed
out), i'm totally happy with it, and if enough people want it i can make a
last effort to cleanup and format it accordingly to the cocoon project base
rules.
Regards.
Re: Suggestion for XHTMLSerializer
Posted by "Roy G. Biv" <mi...@pcextremist.com>.
Forgive me for jumping in, but people seem to be talking past one
another. I don't think you are talking about the same issue(s). Correct
me if I'm wrong.
Vadim Gritsenko wrote:
> Joerg Heinicke wrote:
>
>> On 08.08.2005 21:30, Vadim Gritsenko wrote:
>>
>>>>> Completely wrong. If you find a 1:1 relation between a svg and a
>>>>> bitmap, go
>>>>> ahead man, you're rich. For me a svg serialization is not
>>>>> reversible, you
>>>>> loose layers, labels, structure and of course scalability.
>>>>
>>>> Man, 1:1 does not mean that you can go in both directions!
>>>
>>> You just proved Eric's point.
>>
>> In which way?
>
> XSLT serialization (as per spec Eric quoted) provides a way for "one
> way 1:1 transformation" of xml into the desired view format exactly in
> the same way as batik transforms svg into png. XSLT has more
> capabilities, one even might say that it allows for arbitrary xml
> transformations - but another will say that's exactly the
> transformation he needs for his view.
From Vadim and Eric: Many (most?) serializers are not reversible and
therefore there should be no prohibition on yet another seemingly useful
serializer based upon XSLT and its output element.
From Joerg: An XSLSerializer (or TRAXSerializer) would require a src
attribute and so depend on something outside the sitemap for its
behavior. This is a question of side effects.
These are two separate and distinct design/implementation issues.
>> Furthermore there were reasons for not using xsl:output information,
>> but putting it into serializer component declaration. Shall they no
>> longer be valid?
>
> Design of the Cocoon components does not force you into using
> xsl:output instruction. Moreover, you are encouraged to split up your
> transformations into multiple logically separated stages, some of them
> transforming xml data and some of them applying view, layout, etc
> details, (and some of them even doing LDAP or SQL DB lookups) and
> finally, you have an option to serialize this xml into the output
> format of your choosing.
>
> TraxSerializer does not break above design in any single place. It
> just gives you additional serialization option, which is,
> coincidentally, explores well documented and understood option of the
> XSLT specification, which is a plus in my book.
That "well documented and understood option of the XSLT specification"
was categorically rejected when designing Cocoon 2.x. It was obviously
intended for standalone use just as processing instructions in XML to
determine the XSLT or CSS stylesheet. It is fundamentally at odds with
the Cocoon pipeline, as has been mentioned on the mailing list for years.
> TraxSerializer does not force you to put your final view xslt
> transform into the serializer. And I'd even discourage you to do it -
> as it, in some scenarios, reduces possibilities of reuse - but in some
> scenarios it'd be advantageous to add small xslt based serialization
> instead of writing yet another java serializer.
Can you enumerate these scenarios? What could you do for this that you
cannot do with a trax transformer followed by one of the existing
serializers? What advantage is there over, say, a virtual serializer
made up of an xslt transform and a serializer? What is the specific use
case?
Use cases that currently cannot be handled easily = excellent reason.
But "some scenarios" sounds like (dare I say it?) Flexibility Syndrome.
Now, to add some more fodder to this discussion... Are there any other
serializers that rely on non-sitemap assets such as template files for
operation? Batik uses AWT behind the scenes and the system fonts for
example, but does this count? Wouldn't something like a TRAXSerializer
add side effects to the concept of sitemap serializers? Currently the
sitemap is as much a processing contract as it is a processor. By
looking at the sitemap pipeline, you can see what should be read, what
the schema/format is at each stage of the pipeline, and exactly what is
sent out.
The svg2jpeg serializer is not 1:1 as Vadim and Eric have pointed out.
They are not equal. However, this does not invalidate Joerg's point. It
is a *completely different* point. A better, clearer statement is that
serializers are not 1:1 (to be clear, nothing in Cocoon 2 is) but rather
1->1. There have been no end of emails equating reversibility (1:1) to a
processing anti-pattern. Currently, what you see in the sitemap
serializer declaration is what is output. Introducing a trax serializer
means that what you see in the sitemap serializer declaration is only
*part* of what is output. There is a huge difference between the two,
and I can see why Joerg was so upset.
* The svg2jpeg serializer always requires SVG input and always provides
JPEG output -- including the mime type of image/jpeg.
* The fo2pdf serizalizer always requires XSL:FO input and always
provides PDF output -- including the mime type of application/pdf.
* A hypothetical trax serializer would require a specific input
(elements that the stylesheet is expecting) but the output is...? HTML
sometimes, generic XML other times, etc.?
It can't do it now, but what if someone writes an SVG-to-raster output
plugin to Xalan? Would it be acceptable or clear to have HTML sometimes,
generic XML other time, and a binary format still other times?
Also, don't underestimate the value of having XSLT only in the middle of
a pipeline. Why? The sitemap maintainer can look at a pipeline
declaration and see that a stylesheet has specific input and specific
output. How so?
<!-- My input source may be variable, but the output must match the next
link in the chain -->
<map:generate src="myxml"/>
<!-- The transformer must be written to the expected generator output. -->
<map:transform src="schema1toSVG.xsl"/>
<!-- The transformer must output the correct format, in this case SVG,
or the serializer breaks.
The serializer always expects SVG and always outputs JPEG. -->
<map:serialize type="svg2jpeg"/>
In that example, I can look at the sitemap and know exactly what's going
on. Compare this to a TRAXSerializer example:
<map:generate src="myxml"/>
<!-- The generator output must be exact or the XSLT won't match elements
correctly.
The serializer must be written to the expected generator output. -->
<map:serialize type="trax">
<map:parameter name="xslt" value="stylesheet.xsl"/>
</map:serialize>
In the second example, I know what went in, but I have absolutely no
idea what happens to it unless I as the sitemap maintainer also know
XSLT as well. I am completely dependent upon the filename of the
stylesheet for a functionality hint. It gets even more fun with stuff
like the following:
<map:serialize type="trax">
<map:parameter name="xslt" value="cocoon:/stylesheet.xsl"/>
</map:serialize>
Let's take this to its logical conclusion. When would you ever want to
have the output type be dynamically assigned by the serializer
stylesheet? After all, this is the *only* reason for TRAXSerializer
rather than an XMLSerializer with a specified doctype. What is the use
case? If it's static and the stylesheet output type and mime/type never
changes, the only thing you've gained is a sitemap that isn't as clear
as to what was going on in the pipeline.
Having the logic (XSLT stylesheet in this case) determine the processing
-- specifically the output portion of the sitemap process -- sends us
back to Cocoon 1.x, doesn't it? Is ProcessingInstructionTransformer far
behind where the processing instruction in the source XML stream
determines the stylesheet to use? Don't kid yourself. That's what we're
talking about with a TRAXSerializer.
I completely agree with Joerg.
My $0.02,
Miles Elam
Re: Suggestion for XHTMLSerializer
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Joerg Heinicke wrote:
> On 08.08.2005 21:30, Vadim Gritsenko wrote:
>
>>>> Completely wrong. If you find a 1:1 relation between a svg and a
>>>> bitmap, go
>>>> ahead man, you're rich. For me a svg serialization is not
>>>> reversible, you
>>>> loose layers, labels, structure and of course scalability.
>>>
>>> Man, 1:1 does not mean that you can go in both directions!
>>
>> You just proved Eric's point.
>
> In which way?
XSLT serialization (as per spec Eric quoted) provides a way for "one way 1:1
transformation" of xml into the desired view format exactly in the same way as
batik transforms svg into png. XSLT has more capabilities, one even might say
that it allows for arbitrary xml transformations - but another will say that's
exactly the transformation he needs for his view.
> Furthermore there were reasons for not using xsl:output information, but
> putting it into serializer component declaration. Shall they no longer
> be valid?
Design of the Cocoon components does not force you into using xsl:output
instruction. Moreover, you are encouraged to split up your transformations into
multiple logically separated stages, some of them transforming xml data and some
of them applying view, layout, etc details, (and some of them even doing LDAP or
SQL DB lookups) and finally, you have an option to serialize this xml into the
output format of your choosing.
TraxSerializer does not break above design in any single place. It just gives
you additional serialization option, which is, coincidentally, explores well
documented and understood option of the XSLT specification, which is a plus in
my book.
TraxSerializer does not force you to put your final view xslt transform into the
serializer. And I'd even discourage you to do it - as it, in some scenarios,
reduces possibilities of reuse - but in some scenarios it'd be advantageous to
add small xslt based serialization instead of writing yet another java serializer.
Vadim
Re: Suggestion for XHTMLSerializer
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Joerg Heinicke wrote:
> On 08.08.2005 21:30, Vadim Gritsenko wrote:
...
>> Moreover, I don't see why go all religious on simple and (as it seems)
>> useful idea of XSLSerializer. We do have FOP, Batik, etc serializers -
>> why not Trax.
>
> I don't see how they compare.
>
> Furthermore there were reasons for not using xsl:output information, but
> putting it into serializer component declaration. Shall they no longer
> be valid?
Blocking others on implementing something that they will use, while you
will not use it and while this will not affect your usage, is always a
bad idea.
I have resisted for years in putting in features in the exception
handling in a similar way, only to find that afterwards they got
implemented without any real harm.
In the end, I just prevented others from doing something they wanted.
It was a bad thing to do.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Suggestion for XHTMLSerializer
Posted by Joerg Heinicke <jo...@gmx.de>.
On 08.08.2005 21:30, Vadim Gritsenko wrote:
>>> Completely wrong. If you find a 1:1 relation between a svg and a
>>> bitmap, go
>>> ahead man, you're rich. For me a svg serialization is not reversible,
>>> you
>>> loose layers, labels, structure and of course scalability.
>>
>> Man, 1:1 does not mean that you can go in both directions!
>
>
> You just proved Eric's point.
In which way?
> Moreover, I don't see why go all religious
> on simple and (as it seems) useful idea of XSLSerializer. We do have
> FOP, Batik, etc serializers - why not Trax.
I don't see how they compare.
Furthermore there were reasons for not using xsl:output information, but
putting it into serializer component declaration. Shall they no longer
be valid?
Joerg
Re: Suggestion for XHTMLSerializer
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 8 août 05, à 21:30, Vadim Gritsenko a écrit :
> ...If you want crusades or jihad (take your pick), start with
> XSLGenerator which is already in the trunk for 2 years, 3 months ago
> :-)
Actually we *could* rewrite Cocoon in XSLT, not?
-Bertrand, ducking
Re: Suggestion for XHTMLSerializer
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Joerg Heinicke wrote:
> On 07.08.2005 19:22, BURGHARD Éric wrote:
>
>> Completely wrong. If you find a 1:1 relation between a svg and a
>> bitmap, go
>> ahead man, you're rich. For me a svg serialization is not reversible, you
>> loose layers, labels, structure and of course scalability.
>
> Man, 1:1 does not mean that you can go in both directions!
Joerg,
You just proved Eric's point. Moreover, I don't see why go all religious on
simple and (as it seems) useful idea of XSLSerializer. We do have FOP, Batik,
etc serializers - why not Trax.
If you want crusades or jihad (take your pick), start with XSLGenerator which is
already in the trunk for 2 years, 3 months ago :-)
Vadim
Re: Suggestion for XHTMLSerializer
Posted by Joerg Heinicke <jo...@gmx.de>.
On 07.08.2005 19:22, BURGHARD Éric wrote:
> Completely wrong. If you find a 1:1 relation between a svg and a bitmap, go
> ahead man, you're rich. For me a svg serialization is not reversible, you
> loose layers, labels, structure and of course scalability.
Man, 1:1 does not mean that you can go in both directions!
> I'm tired of this discussion.
Me too.
Joerg
Re: Suggestion for XHTMLSerializer
Posted by Antonio Gallardo <ag...@agssa.net>.
BURGHARD Éric wrote:
>>2 points:
>>
>>1-Nobody is telling you cannot use your own serializers.
>>2- I agree the current standard serializer has bugs. I tried to fix
>>them. I met problems into xalan internals and .... well, it is a very
>>long story. Few weeks ago, I spent most part of 15 nights trying to fix
>>that (weekend included). I went into xalan internals. Can you help us to
>>fix them.? Your help will be very welcomed!
>>
>>
>>
>
>Good point :-). It's true that i said several times that the standard
>serializer has bugs without proposing any help (what a rude guy). I never
>went into xalan internals, and for now i'm more focused on the launching of
>our web project that on anything else, but i would really like to be part
>of the confidence (Really ! xalan has bugs ! :-) just to know if i could
>help.
>
>
Yes, of course! Help is usually very welcome! :-)
Here is the cocoon bug:
http://issues.apache.org/bugzilla/show_bug.cgi?id=34386
Yep. Here is the xalan bug:
http://issues.apache.org/jira/browse/XALANJ-2111
Best Regards,
Antonio Gallardo
Re: Suggestion for XHTMLSerializer
Posted by BURGHARD Éric <er...@systheo.com>.
> 2 points:
>
> 1-Nobody is telling you cannot use your own serializers.
> 2- I agree the current standard serializer has bugs. I tried to fix
> them. I met problems into xalan internals and .... well, it is a very
> long story. Few weeks ago, I spent most part of 15 nights trying to fix
> that (weekend included). I went into xalan internals. Can you help us to
> fix them.? Your help will be very welcomed!
>
Good point :-). It's true that i said several times that the standard
serializer has bugs without proposing any help (what a rude guy). I never
went into xalan internals, and for now i'm more focused on the launching of
our web project that on anything else, but i would really like to be part
of the confidence (Really ! xalan has bugs ! :-) just to know if i could
help.
> Best Regards,
Best regards too.
Re: Suggestion for XHTMLSerializer
Posted by Antonio Gallardo <ag...@agssa.net>.
BURGHARD Éric wrote:
>Again, there is no conceptual difference between generator, transformer,
>serializer, apart the type of their position in the pipeline and so the
>type of their io. They ALL do transformations otherwise they would be very
>unusefull.
>
>
Yep. They share a lot in common. The diference between the is exactly as
you pointed above:
1-The position into a pipeline
2-The I/O between them.
>
>
>>It is not, but if you break your stylesheet into multiple steps
>>(transformer(s) + standard serializer), you can put them together into a
>>virtual serializer.
>>
>Again, i don't have to break it, it's much more
>understandable/readable/efficient in one part, and standard serializers are
>bugged.
>
>
2 points:
1-Nobody is telling you cannot use your own serializers.
2- I agree the current standard serializer has bugs. I tried to fix
them. I met problems into xalan internals and .... well, it is a very
long story. Few weeks ago, I spent most part of 15 nights trying to fix
that (weekend included). I went into xalan internals. Can you help us to
fix them.? Your help will be very welcomed!
Best Regards,
Antonio Gallardo
Re: Suggestion for XHTMLSerializer
Posted by BURGHARD Éric <er...@systheo.com>.
>
> You know what I meant: A serializer just changes the representation of
> the data but does not change the data itself - while this is of course
> not true for the transformers. When you setup your pipeline it is a
> 1:1-relation of SAX input to byte output and does not depend on anything
> else. Your serializer breaks this.
>
Completely wrong. If you find a 1:1 relation between a svg and a bitmap, go
ahead man, you're rich. For me a svg serialization is not reversible, you
loose layers, labels, structure and of course scalability. It's a complex
transformation that involves a lot of calculus and for which the output as
nothing to do (nature & structure) than the input.
Again, there is no conceptual difference between generator, transformer,
serializer, apart the type of their position in the pipeline and so the
type of their io. They ALL do transformations otherwise they would be very
unusefull.
>
> It is not, but if you break your stylesheet into multiple steps
> (transformer(s) + standard serializer), you can put them together into a
> virtual serializer.
>
Again, i don't have to break it, it's much more
understandable/readable/efficient in one part, and standard serializers are
bugged.
I'm tired of this discussion.
Regards.
Re: Suggestion for XHTMLSerializer
Posted by Joerg Heinicke <jo...@gmx.de>.
On 07.08.2005 14:51, BURGHARD Éric wrote:
>>Of course serializers do transformations, you already wrote it: from SAX
>>to bytes. But there is one important difference: The behaviour of a
>>serializer (and at the end the output) is absolutely predictable. If you
>>feed the same SAX events into a specific serializer you will always get
>>the same result.
>
> So the behavior of a transformer is not absolutely predictable ? If i feed
> my xsl transformers with the same stylesheet and the same data, the result
> is hopefully the same. I hope that predictability is a quality shared not
> only among serializers but by all cocoon components ;-).
You know what I meant: A serializer just changes the representation of
the data but does not change the data itself - while this is of course
not true for the transformers. When you setup your pipeline it is a
1:1-relation of SAX input to byte output and does not depend on anything
else. Your serializer breaks this.
>>And to come back to Antonio's absolutely correct interjection about the
>>virtual serializers: This is the point were you can put together again
>>the above mentioned additional transformer steps and the standard
>>serializer.
>
> He was just wondering if this thread was about virtual serialization. It's
> not.
It is not, but if you break your stylesheet into multiple steps
(transformer(s) + standard serializer), you can put them together into a
virtual serializer.
Joerg
Re: Suggestion for XHTMLSerializer
Posted by BURGHARD Éric <er...@systheo.com>.
> I was not wondering, I saw your request exaclty as a "virtual
> serializers" usecase. This is something we want to address for cocoon 2.2.
>
Ok ;-). So 'Is this a virtual component ?' was not a question (i'm joking).
Thanks for (re)joining this discussion.
> I believe, I understand your point: "Process the lastest tranformation
> with the (X)HTML serializer". It is OK. Note that ,as Joerg said, : "It
> is only an implementation matter". Something that the virtual serializer
> need to address. I am sure this will save us "one SAX event generation
> step" in this special case.
Yes of course. On our project, 90% of the pipelines are of that kind
(finished by an xsl transformation). But it's not only to save one sax
event generation which is, as joerg pointed out, an implementation detail.
I'm not talking about implementation details but about xsl processor roles
in the pipeline model of cocoon.
In the xslt spec, you can read: "A processor may output a final result tree
as a sequence of octets, although it is not required to be able to do so".
For those processors which claim to conform to serialization feature, i see
no reason to consider them only as transformers. xsl:output is optional but
is part of the language and clearly defined in the specs. The method
attribute is said to take many values, but xml,html,xhtml and text is a
minimal subset.
This feature is very well implemented in saxon8 (4 serializers in 1), it's
normal for me to use it instead or with the regular serializers. For now,
the XSLSerializer is the only way to do it.
If we are agreed that transformation is a subset of serialization (i could
serialize to sax but i could never transform to jpeg), then it will be
clear for you as it is for me that xsl must be at least as expressive in
the serialization world as it is in the transformation world. That's why
you should not restrict an XSLSerializer to an internal stylesheet or to
some 'well-choosen' parameters.
> Agreed (see above). On the other hand, I think the suggested
> XSLSerializer will requiere a XSL file with a <xsl:output> instruction?
> How we will be able to reuse this XSL file in a tranformer? Thinking 5
> seconds, I see 2 posible solutions (I don't like none of them):
> 1-Copy&paste the XSLT and remove the <xsl:output> tag for tranformer
> usage. 2-Let the XSLTranformer ignore the <xsl:output> tag.
> Can you have a better solution for that?
>
Currently in cocoon the xsltransformer implement 2. I find normal that
xsl:output has no meaning in a transformer since it's related to
serialization (again the idea of subset). What i found annoying is that
there was no way for xsl:output to express itself.
> I read you are tired of this discussion. Me too. It is not the best way
> to discuss this topics by exchanging mails. But this is the only way we
> can discuss right now. Please don't think we are just trying to reject
> your suggestions at any cost. It is not the case. We are trying to give
> you more information about how the things works, the next planned steps.
> We are open minded and what we want the best for cocoon. ;-)
>
Yes me too (open minded i guess). Writing in english is a good exercise but
a frustrating one too. I thank everybody for this discussion (joerg,
jason, ...), forgive me all for my lack of patience ;-)
Regards.
Re: Suggestion for XHTMLSerializer
Posted by Antonio Gallardo <ag...@agssa.net>.
BURGHARD Éric wrote:
>>Of course serializers do transformations, you already wrote it: from SAX
>>to bytes. But there is one important difference: The behaviour of a
>>serializer (and at the end the output) is absolutely predictable. If you
>>feed the same SAX events into a specific serializer you will always get
>>the same result.
>>
>>
>>
>
>So the behavior of a transformer is not absolutely predictable ? If i feed
>my xsl transformers with the same stylesheet and the same data, the result
>is hopefully the same. I hope that predictability is a quality shared not
>only among serializers but by all cocoon components ;-).
>
>
Yes, of course.
>
>
>>And to come back to Antonio's absolutely correct interjection about the
>>virtual serializers: This is the point were you can put together again
>>the above mentioned additional transformer steps and the standard
>>serializer.
>>
>>
>>
>
>He was just wondering if this thread was about virtual serialization. It's
>not.
>
I was not wondering, I saw your request exaclty as a "virtual
serializers" usecase. This is something we want to address for cocoon 2.2.
I believe, I understand your point: "Process the lastest tranformation
with the (X)HTML serializer". It is OK. Note that ,as Joerg said, : "It
is only an implementation matter". Something that the virtual serializer
need to address. I am sure this will save us "one SAX event generation
step" in this special case.
>XSLSerializer is a full featured serializer which can play the role of
>a serializer in a virtual serializer if you really want to virtualize, but
>what's the use of this extra step if i could do it in one, without bugs and
>without breaking any pattern design ?
>
>
Agreed (see above). On the other hand, I think the suggested
XSLSerializer will requiere a XSL file with a <xsl:output> instruction?
How we will be able to reuse this XSL file in a tranformer? Thinking 5
seconds, I see 2 posible solutions (I don't like none of them):
1-Copy&paste the XSLT and remove the <xsl:output> tag for tranformer usage.
2-Let the XSLTranformer ignore the <xsl:output> tag.
Can you have a better solution for that?
I read you are tired of this discussion. Me too. It is not the best way
to discuss this topics by exchanging mails. But this is the only way we
can discuss right now. Please don't think we are just trying to reject
your suggestions at any cost. It is not the case. We are trying to give
you more information about how the things works, the next planned steps.
We are open minded and what we want the best for cocoon. ;-)
Best Regards,
Antonio Gallardo
Re: Suggestion for XHTMLSerializer
Posted by BURGHARD Éric <er...@systheo.com>.
>
> Of course serializers do transformations, you already wrote it: from SAX
> to bytes. But there is one important difference: The behaviour of a
> serializer (and at the end the output) is absolutely predictable. If you
> feed the same SAX events into a specific serializer you will always get
> the same result.
>
So the behavior of a transformer is not absolutely predictable ? If i feed
my xsl transformers with the same stylesheet and the same data, the result
is hopefully the same. I hope that predictability is a quality shared not
only among serializers but by all cocoon components ;-).
>
> And to come back to Antonio's absolutely correct interjection about the
> virtual serializers: This is the point were you can put together again
> the above mentioned additional transformer steps and the standard
> serializer.
>
He was just wondering if this thread was about virtual serialization. It's
not. XSLSerializer is a full featured serializer which can play the role of
a serializer in a virtual serializer if you really want to virtualize, but
what's the use of this extra step if i could do it in one, without bugs and
without breaking any pattern design ?
Regards.
Re: Suggestion for XHTMLSerializer
Posted by Joerg Heinicke <jo...@gmx.de>.
On 07.08.2005 10:53, BURGHARD Éric wrote:
>>Perhaps I overused the term "model". I was referring more to the
>>_Document_Object_ Model (DOM) represented by the various stages of the
>>SAX stream. A generator creates one DOM, a transformer converts that
>>DOM into another, and a serializer takes the DOM resulting from the
>>final transformer and creates a representation of it. It does not
>>modify that DOM.
>
> You see here that a serializer actually do a transformation. The only
> difference is that the resulting transformation always take the form of sax
> events in a transformer (eventually followed by some side affects: sql,
> xmldb, ...), and is a final transformation which could take many different
> forms with a serializer (binary, zip, text, jpeg, xml, ...).
Of course serializers do transformations, you already wrote it: from SAX
to bytes. But there is one important difference: The behaviour of a
serializer (and at the end the output) is absolutely predictable. If you
feed the same SAX events into a specific serializer you will always get
the same result.
If you need some modifications to the XML stream, just add another
transformer. If you need to influence the serialization process, just
configure your serializer component declaration. If the serializer's
configuration does not offer all configuration options, fix the
serializer implementation. But don't mix transformation and
serialization. Or in other words: Until now the usage of the empty
stylesheet in the serializer is a transparent implementation detail.
Your approach will make it a mixture of transformation and serialization.
And to come back to Antonio's absolutely correct interjection about the
virtual serializers: This is the point were you can put together again
the above mentioned additional transformer steps and the standard
serializer.
>>But the important thing is that using an XSLT internally is merely an
>>implementation detail. Exposing the XSLT implementation to users is
>>what Joerg and I take issue with. (Don't mean to speak for you here,
>>Joerg, correct me if I'm misquoting you.)
>
> I'm not exposing the xslt implementation. There is other way of hiding
> implementation than compiling and encrypting a stylesheet in a java class.
> Users should not access the files of your webapp (this is webapp/container
> security), designers should not modify core stylesheets (this is repository
> security).
I don't see your point here.
Joerg
Re: Suggestion for XHTMLSerializer
Posted by Jason Johnston <co...@lojjic.net>.
BURGHARD Éric wrote:
> If you look at the core components, no one follow such a hard constraint.
> Some serializers do radical transformation (svg2jpeg, links, ...), while
> some transformers only do very light transformation (encodeurl, i18n, ...).
>
> If you take the links serializer for example you will find that the output
> is radically different than the input (and this is a serializer). If you
> take the svg2jpeg serializer you will see that the ouput is just a "view"
> of the input, because apart the file format "radicalisation", a lot of
> information disappear during the convertion from vectors to bitmaps. So i
> could perfectly do a silly xsl serialization that only display the root tag
> name of the input (it still a view of my input) and call that a
> serialization.
I was not familiar with the LinkSerializer, so I took a quick look at
it. Your point is well taken here; this serializer appears to be an
anomaly. It acts like a transformer, but happens to do out.println() as
its output instead of SAX events (to be fair, it actually *does* produce
SAX events as well, but those events appear to get swallowed.)
I'm getting a tad off-topic here, but IMO this "serializer" would be a
better fit, and far more useful, as a transformer. For instance, what
if I wanted to serialize the extracted links as a PDF document instead
of text, or run another transformation on them before serializing?
Having the link extraction transformation and serialization combined
together does not allow this.
As far as svg2jpg, I don't see your point. Every last bit of the SVG is
taken into account when producing the bitmap representation.
Re: Suggestion for XHTMLSerializer
Posted by BURGHARD Éric <er...@systheo.com>.
>> I don't understand here. How could i modify a model with an xsl
>> transformation (and by extension an xsl serialization) ? XSL is for
>> generating views from a sax representation of a model (not to be confused
>> with the model itself. It's generated at the beginning of the pipeline by
>> the generator). As far as you don't write nasty java extension to your
>> processor (do you really need xsl for nasty java ?), i don't see how you
>> can achieve such side effects with xsl (ie writing to your DB which IS
>> the model).
>
> Perhaps I overused the term "model". I was referring more to the
> _Document_Object_ Model (DOM) represented by the various stages of the
> SAX stream. A generator creates one DOM, a transformer converts that
> DOM into another, and a serializer takes the DOM resulting from the
> final transformer and creates a representation of it. It does not
> modify that DOM.
>
So now it's your turn to talk about implementation details ;-) Honestly i
think you're wrong with that approach. The sitemap controller is a
controller in the MVC world, and a un pipeline is kind of execution unit of
that controller. It's said nowhere that you should not modify model or dom
or whatever in the first stages of the pipeline and not in others stages.
It's like you said that in the flow controller, you should not access the
model after the first line or modify the dom after the third.
If you look at the core components, no one follow such a hard constraint.
Some serializers do radical transformation (svg2jpeg, links, ...), while
some transformers only do very light transformation (encodeurl, i18n, ...).
If you take the links serializer for example you will find that the output
is radically different than the input (and this is a serializer). If you
take the svg2jpeg serializer you will see that the ouput is just a "view"
of the input, because apart the file format "radicalisation", a lot of
information disappear during the convertion from vectors to bitmaps. So i
could perfectly do a silly xsl serialization that only display the root tag
name of the input (it still a view of my input) and call that a
serialization.
You see here that a serializer actually do a transformation. The only
difference is that the resulting transformation always take the form of sax
events in a transformer (eventually followed by some side affects: sql,
xmldb, ...), and is a final transformation which could take many different
forms with a serializer (binary, zip, text, jpeg, xml, ...).
>
> But the important thing is that using an XSLT internally is merely an
> implementation detail. Exposing the XSLT implementation to users is
> what Joerg and I take issue with. (Don't mean to speak for you here,
> Joerg, correct me if I'm misquoting you.)
>
I'm not exposing the xslt implementation. There is other way of hiding
implementation than compiling and encrypting a stylesheet in a java class.
Users should not access the files of your webapp (this is webapp/container
security), designers should not modify core stylesheets (this is repository
security).
>
> Those are absolutely bugs that should be fixed in the current
> serializer(s).
Sure. It already works with xsl, it does not break any design pattern, it's
maintained by others, fully tested and debugged on other projets, what
else ? For all kind of text/xml/html serialization you have a lot simpler,
more robust and more secure way of writing/extending/reusing serializers.
Regards.
Re: Suggestion for XHTMLSerializer
Posted by Jason Johnston <co...@lojjic.net>.
BURGHARD Éric wrote:
>>I agree with Joerg here; by providing the author with the ability to use
>>any .xsl for serialization, you're allowing the serializer to control
>>not only how the model is serialized, but to modify the model itself
>>(which is the role of transformers). This essentially removes the
>>distinction between transformer and serializer, so if a serializer is
>>just another transformer why have it at all? That's how it breaks the
>>pipeline design.
>
> You seems to forgot the main distinction between a serializer and a
> transformer. A transformer process sax events and generate sax events,
> whereas a serializer ends a sax flow, and that's what the xsl serializer is
> doing. I don't see where it breaks the pipeline design.
>
> If you look at existent transformers, quite a few of them could potentially
> modify the model (sql, xmldb, writeDOMSession, ...). IMHO this is not the
> right angle to compare serializers and transformers roles.
I also happen to dislike that pattern, but it's unrelated to the current
discussion.
>>It seems what you'd want instead is to enhance the XML/XHTML/whatever
>>serializer(s) to accept parameters to control all the XML serialization
>>options authors might want. For example:
>>
>><serialize type="xml">
>> <param name="cleanup-namespaces" value="true" />
>> <param name="replace-entities" value="true" />
>> <param name="indent" value="true" />
>> <!-- etc -->
>></serialize>
>>
>>Anything that modifies the actual model should go before the
>>serialization stage as a transformer.
>>
>
>
> I don't understand here. How could i modify a model with an xsl
> transformation (and by extension an xsl serialization) ? XSL is for
> generating views from a sax representation of a model (not to be confused
> with the model itself. It's generated at the beginning of the pipeline by
> the generator). As far as you don't write nasty java extension to your
> processor (do you really need xsl for nasty java ?), i don't see how you
> can achieve such side effects with xsl (ie writing to your DB which IS the
> model).
Perhaps I overused the term "model". I was referring more to the
_Document_Object_ Model (DOM) represented by the various stages of the
SAX stream. A generator creates one DOM, a transformer converts that
DOM into another, and a serializer takes the DOM resulting from the
final transformer and creates a representation of it. It does not
modify that DOM.
>
>>Now, if it turned out that the best/most efficient way to implement the
>>above serializer was with an encapsulated XSLT file (not modifiable by
>>the author), then by all means do it that way, with the possibility of
>>changing the implementation later if something better came along.
>>
>
> sorry, "not modifiable but with the possibility of changing later" seems
> confusing for me.
By this I simply mean that there are many ways you could implement the
behavior we're talking about (control over the serialization details
like indentation, collapsing certain elements, etc.) One possible way,
which IIUC the current XMLSerializer uses, is to use an internal XSLT
stylesheet. But certainly there are other ways, and it may turn out
that using XSLT is not the most efficient, so you could conceivably
change the implementation to achieve the same behavior.
But the important thing is that using an XSLT internally is merely an
implementation detail. Exposing the XSLT implementation to users is
what Joerg and I take issue with. (Don't mean to speak for you here,
Joerg, correct me if I'm misquoting you.)
>>But providing an XSLSerializer greatly lowers the bar for doing those
>>more complicated things. Lowering the bar encourages abuse.
>
> Here i understand that things must stay complicated just to frighten new
> users ;-). I just need some sleep.
Now now, don't twist my words.
>>>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.
>>
>>This much I agree with; if you come to Cocoon for the first time as an
>>experienced XSLT developer who is used to being able to use xsl:output
>>to control the output serialization format, it can be very confusing.
>>But as long as the same capability is offered by the serializer, and
>>it's well-documented, then it's not much of a problem.
>
> I was not experienced before cocoon, but XSL is far more documented than any
> of a single cocoon component so guess where is my best skill today. All
> variant of XHTML Serializer failed to handle correctly some empty tags like
> <inputarea/>, <div/>, or <script/>. This is much of a problem that
> motivated this thread.
Those are absolutely bugs that should be fixed in the current serializer(s).
Re: Suggestion for XHTMLSerializer
Posted by BURGHARD Éric <er...@systheo.com>.
>
> I agree with Joerg here; by providing the author with the ability to use
> any .xsl for serialization, you're allowing the serializer to control
> not only how the model is serialized, but to modify the model itself
> (which is the role of transformers). This essentially removes the
> distinction between transformer and serializer, so if a serializer is
> just another transformer why have it at all? That's how it breaks the
> pipeline design.
>
You seems to forgot the main distinction between a serializer and a
transformer. A transformer process sax events and generate sax events,
whereas a serializer ends a sax flow, and that's what the xsl serializer is
doing. I don't see where it breaks the pipeline design.
If you look at existent transformers, quite a few of them could potentially
modify the model (sql, xmldb, writeDOMSession, ...). IMHO this is not the
right angle to compare serializers and transformers roles.
> It seems what you'd want instead is to enhance the XML/XHTML/whatever
> serializer(s) to accept parameters to control all the XML serialization
> options authors might want. For example:
>
> <serialize type="xml">
> <param name="cleanup-namespaces" value="true" />
> <param name="replace-entities" value="true" />
> <param name="indent" value="true" />
> <!-- etc -->
> </serialize>
>
> Anything that modifies the actual model should go before the
> serialization stage as a transformer.
>
I don't understand here. How could i modify a model with an xsl
transformation (and by extension an xsl serialization) ? XSL is for
generating views from a sax representation of a model (not to be confused
with the model itself. It's generated at the beginning of the pipeline by
the generator). As far as you don't write nasty java extension to your
processor (do you really need xsl for nasty java ?), i don't see how you
can achieve such side effects with xsl (ie writing to your DB which IS the
model).
> Now, if it turned out that the best/most efficient way to implement the
> above serializer was with an encapsulated XSLT file (not modifiable by
> the author), then by all means do it that way, with the possibility of
> changing the implementation later if something better came along.
>
sorry, "not modifiable but with the possibility of changing later" seems
confusing for me.
>
> You shouldn't have to be an XSLT guru either. All you should have to
> know is the sitemap configuration vocabulary.
>
Right. xsl:output and xsl:template are the first things you learn with xsl.
nothing more is needed for your first xsl serializer, and i would really
like to be widely considered as an xsl guru just because i wrote a one line
entity replacement instruction ;-).
>
> But providing an XSLSerializer greatly lowers the bar for doing those
> more complicated things. Lowering the bar encourages abuse.
>
Here i understand that things must stay complicated just to frighten new
users ;-). I just need some sleep.
>> 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 :-).
>
> Good luck re-implementing the svg2png or fop serializers in XSL. ;-)
>
:-D. Now you know why i'm more an enthousiast than an hardcore programmer.
>> 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.
>
> This much I agree with; if you come to Cocoon for the first time as an
> experienced XSLT developer who is used to being able to use xsl:output
> to control the output serialization format, it can be very confusing.
> But as long as the same capability is offered by the serializer, and
> it's well-documented, then it's not much of a problem.
I was not experienced before cocoon, but XSL is far more documented than any
of a single cocoon component so guess where is my best skill today. All
variant of XHTML Serializer failed to handle correctly some empty tags like
<inputarea/>, <div/>, or <script/>. This is much of a problem that
motivated this thread.
Regards.
Re: Suggestion for XHTMLSerializer
Posted by Jason Johnston <co...@lojjic.net>.
BURGHARD Éric wrote:
>>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 agree with Joerg here; by providing the author with the ability to use
any .xsl for serialization, you're allowing the serializer to control
not only how the model is serialized, but to modify the model itself
(which is the role of transformers). This essentially removes the
distinction between transformer and serializer, so if a serializer is
just another transformer why have it at all? That's how it breaks the
pipeline design.
It seems what you'd want instead is to enhance the XML/XHTML/whatever
serializer(s) to accept parameters to control all the XML serialization
options authors might want. For example:
<serialize type="xml">
<param name="cleanup-namespaces" value="true" />
<param name="replace-entities" value="true" />
<param name="indent" value="true" />
<!-- etc -->
</serialize>
Anything that modifies the actual model should go before the
serialization stage as a transformer.
Now, if it turned out that the best/most efficient way to implement the
above serializer was with an encapsulated XSLT file (not modifiable by
the author), then by all means do it that way, with the possibility of
changing the implementation later if something better came along.
> 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 shouldn't have to be an XSLT guru either. All you should have to
know is the sitemap configuration vocabulary.
> 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.
But providing an XSLSerializer greatly lowers the bar for doing those
more complicated things. Lowering the bar encourages abuse.
> 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 :-).
Good luck re-implementing the svg2png or fop serializers in XSL. ;-)
> 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.
This much I agree with; if you come to Cocoon for the first time as an
experienced XSLT developer who is used to being able to use xsl:output
to control the output serialization format, it can be very confusing.
But as long as the same capability is offered by the serializer, and
it's well-documented, then it's not much of a problem.
Re: Suggestion for XHTMLSerializer
Posted by BURGHARD Éric <er...@systheo.com>.
> 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.
Re: Suggestion for XHTMLSerializer
Posted by Antonio Gallardo <ag...@agssa.net>.
Joerg Heinicke wrote:
> On 06.08.2005 11:03, BURGHARD Éric wrote:
>
>>>> I wrote a much more powerfull solution: the XSLSerializer, which
>>>> let you
>>>> control the serialization through an xsl stylesheet (an so use the
>>>> xsl:output tag as well as some template rules to make final cleanup
>>>> like
>>>> namespace deletion or href contextualization). I need to do some
>>>> cleanup,
>>>> and i will submit a patch.
>>>
>>>
>>> This is definitely the wrong approach and will probably be not accepted
>>> for the official Cocoon codebase. The transformer influencing the
>>> pipeline is like a component controlling the component container.
>>> Additionally it makes no sense letting an intermediate transformer set
>>> the serialization method for the end of the pipeline. What about an
>>> I18nTransfomer after your stylesheet? Your approach also reduces the
>>> reusability of the stylesheet as it is tied to a specific output
>>> format.
>>
>>
>> In fact, you must check the source code, this the actual approach
>> with the
>> XMLSerializer. The serialization is done with the xsltprocessor but
>> with an
>> empty stylesheet. The serialization is controlled with the output
>> parameters which are taken from the sitemap configuration blocks (tag
>> names
>> are in fact attributes names of xsl:output). So, if you look closer, the
>> XSLSerializer is in fact an obvious evolution of the actual
>> XMLSerializer:
>> 1. what are the reason of enforcing the serialization method to 'xml'
>> whereas xsltprocessor can do much more (no need to rewrite code in
>> specialized serializer (XHTML serializer), it's already done),
>> 2. why just giving an empty stylesheets to the processor instead of a
>> more
>> sophisticated one which could help for example to get rid of alien
>> namespaces.
>>
>> And obviously, i'm talking about final transformation/serialization.
>> If want
>> to localise my templates, i could write some templates and use
>> efficently
>> the xsl:index to implement i18n:text and others in the final
>> transformation, but i'm using the i18n transformer BEFORE serialization.
>
>
> 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 believe what was discussed is very close to a "virtual serilizer". Is
this a virtual component? If yes, then we call here about : "virtual
serializer". A virtual serializer has optional transformers followed by
a Serializer. See: http://wiki.apache.org/cocoon/GT2003Stefano
Some initial discussions about how to implement virtual components:
http://marc.theaimsgroup.com/?t=108996308200002
http://www.mail-archive.com/dev@cocoon.apache.org/msg24485.html
I hope this helps.
Best Regards,
Antonio Gallardo
>
>
> Joerg
Re: Suggestion for XHTMLSerializer
Posted by Joerg Heinicke <jo...@gmx.de>.
On 06.08.2005 11:03, BURGHARD Éric wrote:
>>>I wrote a much more powerfull solution: the XSLSerializer, which let you
>>>control the serialization through an xsl stylesheet (an so use the
>>>xsl:output tag as well as some template rules to make final cleanup like
>>>namespace deletion or href contextualization). I need to do some cleanup,
>>>and i will submit a patch.
>>
>>This is definitely the wrong approach and will probably be not accepted
>>for the official Cocoon codebase. The transformer influencing the
>>pipeline is like a component controlling the component container.
>>Additionally it makes no sense letting an intermediate transformer set
>>the serialization method for the end of the pipeline. What about an
>>I18nTransfomer after your stylesheet? Your approach also reduces the
>>reusability of the stylesheet as it is tied to a specific output format.
>
> In fact, you must check the source code, this the actual approach with the
> XMLSerializer. The serialization is done with the xsltprocessor but with an
> empty stylesheet. The serialization is controlled with the output
> parameters which are taken from the sitemap configuration blocks (tag names
> are in fact attributes names of xsl:output). So, if you look closer, the
> XSLSerializer is in fact an obvious evolution of the actual XMLSerializer:
> 1. what are the reason of enforcing the serialization method to 'xml'
> whereas xsltprocessor can do much more (no need to rewrite code in
> specialized serializer (XHTML serializer), it's already done),
> 2. why just giving an empty stylesheets to the processor instead of a more
> sophisticated one which could help for example to get rid of alien
> namespaces.
>
> And obviously, i'm talking about final transformation/serialization. If want
> to localise my templates, i could write some templates and use efficently
> the xsl:index to implement i18n:text and others in the final
> transformation, but i'm using the i18n transformer BEFORE serialization.
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.
Joerg
Re: Suggestion for XHTMLSerializer
Posted by BURGHARD Éric <er...@systheo.com>.
> What XMLSerializer are you talking about? The one in the serializers
> block or the default one?
>
org.systheo.cocoon.serialization.XMLSerializer
>> I wrote a much more powerfull solution: the XSLSerializer, which let you
>> control the serialization through an xsl stylesheet (an so use the
>> xsl:output tag as well as some template rules to make final cleanup like
>> namespace deletion or href contextualization). I need to do some cleanup,
>> and i will submit a patch.
>
> This is definitely the wrong approach and will probably be not accepted
> for the official Cocoon codebase. The transformer influencing the
> pipeline is like a component controlling the component container.
> Additionally it makes no sense letting an intermediate transformer set
> the serialization method for the end of the pipeline. What about an
> I18nTransfomer after your stylesheet? Your approach also reduces the
> reusability of the stylesheet as it is tied to a specific output format.
>
In fact, you must check the source code, this the actual approach with the
XMLSerializer. The serialization is done with the xsltprocessor but with an
empty stylesheet. The serialization is controlled with the output
parameters which are taken from the sitemap configuration blocks (tag names
are in fact attributes names of xsl:output). So, if you look closer, the
XSLSerializer is in fact an obvious evolution of the actual XMLSerializer:
1. what are the reason of enforcing the serialization method to 'xml'
whereas xsltprocessor can do much more (no need to rewrite code in
specialized serializer (XHTML serializer), it's already done),
2. why just giving an empty stylesheets to the processor instead of a more
sophisticated one which could help for example to get rid of alien
namespaces.
And obviously, i'm talking about final transformation/serialization. If want
to localise my templates, i could write some templates and use efficently
the xsl:index to implement i18n:text and others in the final
transformation, but i'm using the i18n transformer BEFORE serialization.
Regards.
Re: Suggestion for XHTMLSerializer
Posted by Vadim Gritsenko <va...@reverycodes.com>.
> On 05.08.2005 13:49, BURGHARD Éric wrote:
>> I wrote a much more powerfull solution: the XSLSerializer, which let you
>> control the serialization through an xsl stylesheet (an so use the
>> xsl:output tag as well as some template rules to make final cleanup like
>> namespace deletion or href contextualization). I need to do some cleanup,
>> and i will submit a patch.
TraxSerializer would be a better name - matches naming of TraxGenerator and
TraxTransformer.
Vadim
Re: Suggestion for XHTMLSerializer
Posted by Joerg Heinicke <jo...@gmx.de>.
On 05.08.2005 13:49, BURGHARD Éric wrote:
> In fact the XMLSerializer didn't take the 'method' parameter into account.
> At least in saxon8 (never test with other xslt processor, but it should
> work too), if you put <xsl:output method="xhtml"/> all tags like div,
> script, or inputarea remains unclosed.
>
> I think this is a bug with XMLSerializer which enforce the method to be
> 'xml'. The folowing simple class let you choose the serialization method.
What XMLSerializer are you talking about? The one in the serializers
block or the default one?
> I wrote a much more powerfull solution: the XSLSerializer, which let you
> control the serialization through an xsl stylesheet (an so use the
> xsl:output tag as well as some template rules to make final cleanup like
> namespace deletion or href contextualization). I need to do some cleanup,
> and i will submit a patch.
This is definitely the wrong approach and will probably be not accepted
for the official Cocoon codebase. The transformer influencing the
pipeline is like a component controlling the component container.
Additionally it makes no sense letting an intermediate transformer set
the serialization method for the end of the pipeline. What about an
I18nTransfomer after your stylesheet? Your approach also reduces the
reusability of the stylesheet as it is tied to a specific output format.
Joerg
Re: Suggestion for XHTMLSerializer
Posted by Litrik De Roy <co...@litrik.com>.
Kees Broenink wrote:
>Éric,
>
>I tried your solution described below but it does not solve the
><script></script> problem...
>
><script type="text/javascript" src="/bxs/3_0_1/bpc/boot.js"></script>
>
>will return:
>
><script type="text/javascript" src="/bxs/3_0_1/bpc/boot.js"
>xml:space="preserve" />
>
>So IE is not happy.
>
>
I work around this by putting a non-breaking space inside the script
element like this :
<script type="text/javascript" src="/bxs/3_0_1/bpc/boot.js"> </script>
PS: Weird thing is that IE does not show the same problem with the "link" element, only the "style" element seems to be effected.
>Regards, Kees
>
--
Litrik De Roy
www.litrik.com
RE: Suggestion for XHTMLSerializer
Posted by Kees Broenink <ke...@backbase.com>.
Éric,
I tried your solution described below but it does not solve the
<script></script> problem...
<script type="text/javascript" src="/bxs/3_0_1/bpc/boot.js"></script>
will return:
<script type="text/javascript" src="/bxs/3_0_1/bpc/boot.js"
xml:space="preserve" />
So IE is not happy.
Regards, Kees
-----------------
public class XMLSerializer2 extends AbstractTextSerializer {
/**
* Set the configurations for this serializer.
*/
public void configure(Configuration conf)
throws ConfigurationException {
super.configure( conf );
}
/**
* Set the {@link OutputStream} where the requested resource should
* be serialized.
*/
public void setOutputStream(OutputStream out) throws IOException {
super.setOutputStream(out);
try {
TransformerHandler handler = this.getTransformerHandler();
handler.getTransformer().setOutputProperties(this.format);
handler.setResult(new StreamResult(this.output));
this.setContentHandler(handler);
this.setLexicalHandler(handler);
} catch (Exception e) {
final String message = "Cannot set XMLSerializer
outputstream";
throw new CascadingIOException(message, e);
}
}
}
Now just configure this serializer in sitemap.xmap like you do with
regular XMLSerializer.
<map:serializer logger="sitemap.serializer.xhtml" mime-type="text/html"
name="xhtml" pool-grow="2" pool-max="64" pool-min="2"
src="org.apache.cocoon.serialization.XMLSerializer2">
<doctype-public>-//W3C//DTD XHTML 1.0
Strict//EN</doctype-public>
<doctype-system>http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd</docty
pe-system>
<encoding>UTF-8</encoding>
<!-- for i6 compat mode-->
<omit-xml-declaration>yes</omit-xml-declaration>
<method>xhtml</method>
<transformer-factory>net.sf.saxon.TransformerFactoryImpl</transformer-fa
ctory>
</map:serializer>
RE: Suggestion for XHTMLSerializer
Posted by Kees Broenink <ke...@backbase.com>.
You basically removed one line of code in the configure() method, right?
this.format.put(OutputKeys.METHOD,"xml");
Cool!!
I will adopt this and see if it works with xalan, saxon and xsltc.
Thanks,
Kees
-----Oorspronkelijk bericht-----
Van: news [mailto:news@sea.gmane.org] Namens BURGHARD Éric
Verzonden: Friday, August 05, 2005 1:50 PM
Aan: dev@cocoon.apache.org
Onderwerp: Re: Suggestion for XHTMLSerializer
Thorsten Scherler wrote:
> On Tue, 2005-08-02 at 11:25 +0200, Antonio Fiol Bonnín wrote:
>> Hello,
>>
>> I am finding a problem with empty elements when serving content with
>> the text/html content type on Firefox.
>
>> For example, collapsed empty div elements cause havoc in firefox. A
>> possible workaround would be implementing the compatibility
>> guidelines indicated in the W3C recommendations.
>>
>> In particular, I would add the same check already present for style,
>> script and textarea for any element whose end tag is required in HTML
>> 4.01.
>>
>
I found a simple solution to this problem.
In fact the XMLSerializer didn't take the 'method' parameter into
account. At least in saxon8 (never test with other xslt processor, but
it should work too), if you put <xsl:output method="xhtml"/> all tags
like div, script, or inputarea remains unclosed.
I think this is a bug with XMLSerializer which enforce the method to be
'xml'. The folowing simple class let you choose the serialization
method.
public class XMLSerializer2 extends AbstractTextSerializer {
/**
* Set the configurations for this serializer.
*/
public void configure(Configuration conf)
throws ConfigurationException {
super.configure( conf );
}
/**
* Set the {@link OutputStream} where the requested resource should
* be serialized.
*/
public void setOutputStream(OutputStream out) throws IOException {
super.setOutputStream(out);
try {
TransformerHandler handler = this.getTransformerHandler();
handler.getTransformer().setOutputProperties(this.format);
handler.setResult(new StreamResult(this.output));
this.setContentHandler(handler);
this.setLexicalHandler(handler);
} catch (Exception e) {
final String message = "Cannot set XMLSerializer
outputstream";
throw new CascadingIOException(message, e);
}
}
}
Now just configure this serializer in sitemap.xmap like you do with
regular XMLSerializer.
<map:serializer logger="sitemap.serializer.xhtml" mime-type="text/html"
name="xhtml" pool-grow="2" pool-max="64" pool-min="2"
src="org.apache.cocoon.serialization.XMLSerializer2">
<doctype-public>-//W3C//DTD XHTML 1.0
Strict//EN</doctype-public>
<doctype-system>http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd</docty
pe-system>
<encoding>UTF-8</encoding>
<!-- for i6 compat mode-->
<omit-xml-declaration>yes</omit-xml-declaration>
<method>xhtml</method>
<transformer-factory>net.sf.saxon.TransformerFactoryImpl</transformer-fa
ctory>
</map:serializer>
I wrote a much more powerfull solution: the XSLSerializer, which let you
control the serialization through an xsl stylesheet (an so use the
xsl:output tag as well as some template rules to make final cleanup like
namespace deletion or href contextualization). I need to do some
cleanup, and i will submit a patch.
Regards
Re: Suggestion for XHTMLSerializer
Posted by BURGHARD Éric <er...@systheo.com>.
Thorsten Scherler wrote:
> On Tue, 2005-08-02 at 11:25 +0200, Antonio Fiol Bonnín wrote:
>> Hello,
>>
>> I am finding a problem with empty elements when serving content with
>> the text/html content type on Firefox.
>
>> For example, collapsed empty div elements cause havoc in firefox. A
>> possible workaround would be implementing the compatibility guidelines
>> indicated in the W3C recommendations.
>>
>> In particular, I would add the same check already present for style,
>> script and textarea for any element whose end tag is required in HTML
>> 4.01.
>>
>
I found a simple solution to this problem.
In fact the XMLSerializer didn't take the 'method' parameter into account.
At least in saxon8 (never test with other xslt processor, but it should
work too), if you put <xsl:output method="xhtml"/> all tags like div,
script, or inputarea remains unclosed.
I think this is a bug with XMLSerializer which enforce the method to be
'xml'. The folowing simple class let you choose the serialization method.
public class XMLSerializer2 extends AbstractTextSerializer {
/**
* Set the configurations for this serializer.
*/
public void configure(Configuration conf)
throws ConfigurationException {
super.configure( conf );
}
/**
* Set the {@link OutputStream} where the requested resource should
* be serialized.
*/
public void setOutputStream(OutputStream out) throws IOException {
super.setOutputStream(out);
try {
TransformerHandler handler = this.getTransformerHandler();
handler.getTransformer().setOutputProperties(this.format);
handler.setResult(new StreamResult(this.output));
this.setContentHandler(handler);
this.setLexicalHandler(handler);
} catch (Exception e) {
final String message = "Cannot set XMLSerializer outputstream";
throw new CascadingIOException(message, e);
}
}
}
Now just configure this serializer in sitemap.xmap like you do with regular
XMLSerializer.
<map:serializer logger="sitemap.serializer.xhtml" mime-type="text/html"
name="xhtml" pool-grow="2" pool-max="64" pool-min="2"
src="org.apache.cocoon.serialization.XMLSerializer2">
<doctype-public>-//W3C//DTD XHTML 1.0
Strict//EN</doctype-public>
<doctype-system>http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd</doctype-system>
<encoding>UTF-8</encoding>
<!-- for i6 compat mode-->
<omit-xml-declaration>yes</omit-xml-declaration>
<method>xhtml</method>
<transformer-factory>net.sf.saxon.TransformerFactoryImpl</transformer-factory>
</map:serializer>
I wrote a much more powerfull solution: the XSLSerializer, which let you
control the serialization through an xsl stylesheet (an so use the
xsl:output tag as well as some template rules to make final cleanup like
namespace deletion or href contextualization). I need to do some cleanup,
and i will submit a patch.
Regards
Re: Suggestion for XHTMLSerializer
Posted by Thorsten Scherler <th...@apache.org>.
On Tue, 2005-08-02 at 11:25 +0200, Antonio Fiol Bonnín wrote:
> Hello,
>
> I am finding a problem with empty elements when serving content with
> the text/html content type on Firefox.
> For example, collapsed empty div elements cause havoc in firefox. A
> possible workaround would be implementing the compatibility guidelines
> indicated in the W3C recommendations.
>
> In particular, I would add the same check already present for style,
> script and textarea for any element whose end tag is required in HTML
> 4.01.
>
Yes, in Apache Forrest we run into the same problem.
http://marc.theaimsgroup.com/?l=forrest-dev&m=112256252600650&w=2
If you have the class already open: ;-)
  will not be transformed to . A dev reported on his system
it get rendered  (same thread). IMO we should output   to
like in the html serializer.
WDYT?
> Would a patch for this be welcome?
>
Yes, please add it to the issue tracker. :) TIA
> Yours,
>
> --
> Antonio
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
O
RE: Suggestion for XHTMLSerializer
Posted by Kees Broenink <ke...@backbase.com>.
Yes sorry, my fault. I was using the default configuration of cocoon
2.1.7
<map:serializer logger="sitemap.serializer.xhtml"
mime-type="text/html" name="xhtml" pool-max="64"
src="org.apache.cocoon.serialization.XMLSerializer">
I was not aware of the xhtmlserializer class in blocks/serializers. Now
I am! Thx.
Kees
-----Oorspronkelijk bericht-----
Van: Antonio Fiol Bonnín [mailto:antonio.fiol@gmail.com]
Verzonden: Tuesday, August 02, 2005 12:16 PM
Aan: dev@cocoon.apache.org; kees.broenink@backbase.com
Onderwerp: Re: Suggestion for XHTMLSerializer
Maybe I read the code the wrong way. What I understood was:
public void endElementImpl(String uri, String local, String qual)
throws SAXException {
[...]
if (XHTML1_NAMESPACE.equals(uri)) {
if ((local.equalsIgnoreCase("textarea")) ||
(local.equalsIgnoreCase("script")) ||
(local.equalsIgnoreCase("style"))) {
this.closeElement(false); // This line should cause the
[<script] to become [<script>]
} else if (local.equalsIgnoreCase("head")) {
[...]
}
}
super.endElementImpl(uri, local, qual); // And thus this line
should close the element with [</script>]
}
So my proposal would be to add a line like
(local.equalsIgnoreCase("div")) ||
for each element that should share this behaviour.
BTW, the source I am looking at is the one in Cocoon 2.1.7. I checked on
http://svn.apache.org/repos/asf/cocoon/blocks/serializers/trunk/java/org
/apache/cocoon/components/serializers/XHTMLSerializer.java
<http://svn.apache.org/repos/asf/cocoon/blocks/serializers/trunk/java/or
g/apache/cocoon/components/serializers/XHTMLSerializer.java>
and the relevant part of the code is the same.
--
Antonio
2005/8/2, Kees Broenink <ke...@backbase.com>:
Hello,
Adding to this is an issue with IE and the <script> tag. I did not
search the mail archive nor bugzilla, so maybe it is already addressed
for the next release.
The xhtml serializer will change
<script type="text/javascript" src="/bxs/3_0_1/bpc/boot.js"></script>
into
<script type="text/javascript" src="/bxs/3_0_1/bpc/boot.js"/>
This will break loading the JS in IE.
Kees
-----Oorspronkelijk bericht-----
Van: Antonio Fiol Bonnín [mailto:antonio.fiol@gmail.com]
Verzonden: Tuesday, August 02, 2005 11:26 AM
Aan: dev@cocoon.apache.org
Onderwerp: Suggestion for XHTMLSerializer
Hello,
I am finding a problem with empty elements when serving content with the
text/html content type on Firefox. For example, collapsed empty div
elements cause havoc in firefox. A possible workaround would be
implementing the compatibility guidelines indicated in the W3C
recommendations.
In particular, I would add the same check already present for style,
script and textarea for any element whose end tag is required in HTML
4.01.
Would a patch for this be welcome?
Yours,
--
Antonio
Re: Suggestion for XHTMLSerializer
Posted by Antonio Fiol Bonnín <an...@gmail.com>.
Maybe I read the code the wrong way. What I understood was:
public void endElementImpl(String uri, String local, String qual) throws
SAXException {
[...]
if (XHTML1_NAMESPACE.equals(uri)) {
if ((local.equalsIgnoreCase("textarea")) ||
(local.equalsIgnoreCase("script")) ||
(local.equalsIgnoreCase("style"))) {
this.closeElement(false); // This line should cause the [<script] to become
[<script>]
} else if (local.equalsIgnoreCase("head")) {
[...]
}
}
super.endElementImpl(uri, local, qual); // And thus this line should close
the element with [</script>]
}
So my proposal would be to add a line like
(local.equalsIgnoreCase("div")) ||
for each element that should share this behaviour.
BTW, the source I am looking at is the one in Cocoon 2.1.7. I checked on
http://svn.apache.org/repos/asf/cocoon/blocks/serializers/trunk/java/org/apache/cocoon/components/serializers/XHTMLSerializer.java
and the relevant part of the code is the same.
--
Antonio
2005/8/2, Kees Broenink <ke...@backbase.com>:
>
> Hello,
>
> Adding to this is an issue with IE and the <script> tag. I did not
> search the mail archive nor bugzilla, so maybe it is already addressed
> for the next release.
>
> The xhtml serializer will change
> <script type="text/javascript" src="/bxs/3_0_1/bpc/boot.js"></script>
> into
> <script type="text/javascript" src="/bxs/3_0_1/bpc/boot.js"/>
>
> This will break loading the JS in IE.
>
> Kees
>
>
> -----Oorspronkelijk bericht-----
> Van: Antonio Fiol Bonnín [mailto:antonio.fiol@gmail.com]
> Verzonden: Tuesday, August 02, 2005 11:26 AM
> Aan: dev@cocoon.apache.org
> Onderwerp: Suggestion for XHTMLSerializer
>
>
> Hello,
>
> I am finding a problem with empty elements when serving content with the
> text/html content type on Firefox. For example, collapsed empty div
> elements cause havoc in firefox. A possible workaround would be
> implementing the compatibility guidelines indicated in the W3C
> recommendations.
>
> In particular, I would add the same check already present for style,
> script and textarea for any element whose end tag is required in HTML
> 4.01.
>
> Would a patch for this be welcome?
>
> Yours,
>
> --
> Antonio
>
>
RE: Suggestion for XHTMLSerializer
Posted by Kees Broenink <ke...@backbase.com>.
Hello,
Adding to this is an issue with IE and the <script> tag. I did not
search the mail archive nor bugzilla, so maybe it is already addressed
for the next release.
The xhtml serializer will change
<script type="text/javascript" src="/bxs/3_0_1/bpc/boot.js"></script>
into
<script type="text/javascript" src="/bxs/3_0_1/bpc/boot.js"/>
This will break loading the JS in IE.
Kees
-----Oorspronkelijk bericht-----
Van: Antonio Fiol Bonnín [mailto:antonio.fiol@gmail.com]
Verzonden: Tuesday, August 02, 2005 11:26 AM
Aan: dev@cocoon.apache.org
Onderwerp: Suggestion for XHTMLSerializer
Hello,
I am finding a problem with empty elements when serving content with the
text/html content type on Firefox. For example, collapsed empty div
elements cause havoc in firefox. A possible workaround would be
implementing the compatibility guidelines indicated in the W3C
recommendations.
In particular, I would add the same check already present for style,
script and textarea for any element whose end tag is required in HTML
4.01.
Would a patch for this be welcome?
Yours,
--
Antonio