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.

-- 
Domain in provider transition, hope for smoothness. Planed date is 1.7.2003.

Reply via email to