>On Tuesday 03 June 2003 22:29, Joerg Heinicke wrote: JH> 1: A solution for the HTMLSerializer was discussed JH> (startPrefixMapping(), endPrefixMapping()). Maybe TidySerializer JH> provides a better solution, but I guess this can be adapted too.
A little more would be nercessary. You would have to map all xhtml namespace to default prefix and remove the declaration. All other namespaces would have to generate an error. When I know someone will commit it, I can make this patch for HTMLSerializer.
IMO this (a patch to HTMLSerializer) is the best option we have and I'm sure it will be applied.
>JH> 2: Human readability is as you say for debugging reasons. This needs not JH> to be done on live systems. We use IMO a better way: on the last JH> transformer step we add a label="format". We access a page in debugging JH> mode via test.html?cocoon-view=format. The view "format" is simply a JH> further transformer step using format.xsl and the XMLSerializer. The JH> different between live and debugging mode is the URL, not the sitemap. JH> And there is no need for second component.
You can use tidyserializer for the same via views. For this purpose, a stylesheet would also be OK. But it wouldn't be simply indenting. You have to check for xml:strip-space and friends. That's why I haven't done it so far.
For debug output I normalize-space every text node and simply indent them by counting the ancestor nodes. This has no influence for HTML, because HTML normalizes text nodes too (exception: <pre/>).
JH> 3: Also only for debugging, isn't it?
Yesno. I want it as part of quality assurance.
Understandable ...
JH> Validating every request on live systems is too much resource consuming.
Not that real, when it (hopefully) is integrated in xalan some time. For xslt 2.0 type handling, there has to be (IMHO) validation inside. It only has to be forceable for output.
But it's also resource consuming if it's integrated in Xalan :)
JH> And what do you want to do on JH> live systems when a validation error occurs? A message "We can't deliver JH> the page, because it's not valid HTML"?
Redirecting to a internal error page, like with other errors to.
What's the advantage for the user? Who cares about invalid HTML pages? It's only important for development, must no be running on live systems.
JH> But you have other JH> possibilities, e.g. using http://validator.w3.org/ or a mix of Jakarta JH> commons httpclient with Tidy as we did. If you integrate this in a test JH> system you can validate your pages automatically.
That's what I actually do more or less. I validate all generated files via xmllint. I am looking for a cleaner solution which enforces this already in cocoon. When this is a parameter or a view, even better.
Ok, reason accepted :) But what about an extra validating transformer as last pipeline step? Seems to make more sense IMO.
Joerg