Re: Another viewpoint on validation

On 31 March 2012 03:45, Arved Sandstrom <asandstrom2@eastlink.ca> wrote:
> 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?

Time to run such a check? Especially with jvm load times.
What if 2 processors disagree?

>
> 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?

 As Tony noted, many users are interested in 'is featire X supported
by Y processor'


>
> 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.

Yes, for their definition/ interpretation of the spec. We know there
have been disagreements, dual interpretations.


>
> 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.

If error handling were a part of the spec, I'd agree with this. #fail
isn't defined?


regards



-- 
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk

Received on Saturday, 31 March 2012 06:23:37 UTC