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".
Cheers,
-- Abel Braaksma