cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <>
Subject Re: TidySerializer
Date Wed, 04 Jun 2003 19:09:46 GMT
In conclusion:
1. We need a patch for the HTMLSerializer for the namespace issue.
2. A validation transformer seems to be really welcome.
3. For human readability we do not need really a new serializer. What 
about the indent parameter on the serializer (like indent in 
<xsl:output/>)? At the moment you can set it to true, but this only adds 
line breaks AFAIK and does not indent the code. Maybe we simply need a 
patch too?


Torsten Knodt wrote:
> On Tuesday 03 June 2003 23:46, Joerg Heinicke wrote:
> JH> For debug output I normalize-space every text node and simply indent
> JH> them by counting the ancestor nodes. This has no influence for HTML,
> JH> because HTML normalizes text nodes too (exception: <pre/>).
> Right, would be enough for html. And for others? tidy can also work on normal 
> xml and do this. There you need strip-space.
> JH> But it's also resource consuming if it's integrated in Xalan :)
> XSLT 2.0 will consume some resources yes, but computers get faster. And the 
> features of 2.0 help in many cases (like grouping of data).
> BTW: Why does nearly everyone get afraid of resource usage for security or 
> quality checks and spend all resources for flash, videos and others?
> JH> TK> Redirecting to a internal error page, like with other errors to.
> JH> What's the advantage for the user? Who cares about invalid HTML pages?
> JH> It's only important for development, must no be running on live systems.
> First, it shouldn't be to often, that an internal error occurs. When, I think 
> it is better to have an error page, than invalid output. When you get this 
> invalid output after the development phase, you can't be sure where the 
> problem is. Perhaps your transformation process has an error, which also 
> gives wrong data on which the users makes decisions. Also bots or agents 
> parsing the data should interest valid output.
> Also filtering proxys can make good use of valid content. They do not have to 
> do regular expression matching or things like this. They can read their html 
> and xmlize it or take the xml, validate it (and it will be valid) and then do 
> their filtering on a nice DOM tree or SAX stream.
> JH> > cocoon. When this is a parameter or a view, even better.
> JH> Ok, reason accepted :) But what about an extra validating transformer as
> JH> last pipeline step? Seems to make more sense IMO.
> This would be the perfect solution.
> I've already looked how this could be done.
> But at least xerces can only do validation on an input stream or DOM tree. And 
> even on the DOM tree only with XML Schema, when I have read right. At least 
> for the servlet environment, I would prefer a SAX solution.

View raw message