Re: [xsl] Schema-aware validation of XHTML result-document

Subject: Re: [xsl] Schema-aware validation of XHTML result-document
From: "Jesper Tverskov" <jesper@xxxxxxxxxxx>
Date: Fri, 9 Mar 2007 13:55:06 +0100
I think we should put full focus on the one remaining issue, as Andrew
Welch wrote:

I guess what you asking for here is that the original pre-validation
result is serialised rather than the post-validation result - this
would mean the defaulted values not present in your result would be
added for the validation and then discarded, leaving your
pre-validation result intact.  (much like when you just check a file
on disk for validity - it isn't left with defaulted values after

Its certainly raised an interesting question - should the serialised
version of the validated result be the per or post validation


On 3/9/07, Abel Braaksma <> wrote:

Jesper Tverskov wrote: > When I use runtime validation the error message is only good when the > errors are not treated as warnings, but bad in the "warning" mode: > just "One or more validation errors were reported". In both modes > nothing is highlighted in the stylesheet.

Yes, this is a problem with Oxygen. I use it too, and many messages are
not included in full, sometimes they say just "error occurred" or
something like that. It is strange, because Saxon has a very clear and
easy to use error reporting system, and in my own Java backend system
all errors are captured with extensive detail.

My workaround: if you have an unclear error because Oxygen did not
correctly capture it, run it from the commandline and you get the
original clear message from Saxon.

> I understand that XHTML is a special XML-case, but I don't think we
> disagree on anything here. XSLT processors should be improved to make
> also XHTML result-documents valid, when they say so.

This is of course impossible. XSLT can create XML that is schema-valid,
and multiple schema's can be used. It is against the nature of XML and
Schema's to reject documents that are valid, that would be utterly backward.

The best thing a parser can do (and should do, I believe) is use the
room that the spec leaves it for optimizing XHTML when the output method
is set to "xhtml". That is, not closing certain empty tags like <script
src="bla.js"></script>, which would've been closed if XML were the
output method. But to make the output XHTML valid is something very
different from making it (xhtml) Schema valid.

> Are you
> serious? Most of us can easily add templates to our styleheets, but it
> is not a proper way forward in most use cases to open op schemas and
> modify them just to do result-document validation.

I do it all the time when my output format requirements change and
that's certainly a common use case. But I wouldn't open up a
standardized document as XHTML, instead, I would add extra schema's to
it to accommodate for my own specific extra needs.

> It might be against the last detail of the spec, but AltovaXML has
> taken this approach: why not be better than the spec, when it is so
> wrong, that validation of result-documents become almost a joke, if we
> follow the spec to the word.

No, I think you misinterpret the note from Colin here. The spec just
says nothing about what means a processor supports for getting external
resources, it may even support none (but that would not be very useful).
Of course, if you claim to support the http: scheme for looking up
resources, it is a bug if it doesn't work, but it has nothing to do with
being non-conformant to the spec.

About not following the spec to the word: I surely hope they do and that
each vendor uses the extension mechanisms (and there are a lot of them)
to treat users to all kinds of great features that they added to their
product (Saxon has many of them, unfortunately AltovaXML is still far
from conformant and has very few extensions).

> Why not a new "being better than the spec" mode also for Saxon, some
> parameter to use at the command line?

Opinions vary of course, but in outbeating the spec, Saxon sure is the
number one processor for ahead of competitors, stuffed with features not
directly necessary if you would make your product be "just compliant".

-- Abel Braaksma

Jesper Tverskov

Current Thread