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