- From: Arved Sandstrom <asandstrom2@eastlink.ca>
- Date: Fri, 30 Mar 2012 23:45:15 -0300
- To: public-ppl@w3.org
I sort of touched on this in a previous post (I think), but I'll recast it. Rather than focus solely on schema-based validation of XSL-FO XML, why not consider that running a conforming processor (drawn from http://www.w3.org/community/ppl/wiki/XSL-FO_Processors that Tony posted), or running a suitable small set of processors, on the XSL-FO XML in question, is perhaps the most practical validation method? A lot of other technology areas have reference implementations. We don't have that per se for XSL-FO but we do have a situation where many of the processors do publish compliance/conformance information, which can be vetted. As a user I think I would be substantially less concerned about the theoretical validity of an XSL-FO file than I would be in (1) whether a processor nominally supports the formatting objects I need and (2) if so does this processor support them correctly? I realize this may sound somewhat heretical. I use XML in real life quite a lot on various jobs for clients, and more often than not validation is essential - it allows applications to dispense with a great deal of checking that would otherwise have to be done in code, and concentrate on happy-path processing of XML input that is known to correctly conform to a schema. In the case of FO processors, though - correct me if my dated assumptions are wrong - I believe that they are effectively written as if they were validators as well. After all you still design and implement primarily off the specification. So a given module of code that deals with a given FO has expectations as to what it will see for attributes and child elements: if things aren't right you get a planned error or exception in a well-written processor. That *is* validation. I'd be interested in hearing the arguments for validation separate from simply running a good FO processor on the input document in question. For example, I am professionally interested in using XSL-FO in the IBM FileNet DITA publishing space, but I am still not convinced of the practical utility of separately running a schema-based validator on the input documents first. Not when I can simply attempt the processing and catch exceptions: for my purposes I simply care that I could, or could not, process the document. Just my 2 cents worth. I should actually revise that to 5 cents now that Canada is phasing out pennies. :-) Arved
Received on Saturday, 31 March 2012 02:45:42 UTC