> > 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.
