Cart
|
[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Schema-aware validation of XHTML result-document
 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).
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 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
