W3C home > Mailing lists > Public > public-ppl@w3.org > March 2012

Another viewpoint on validation

From: Arved Sandstrom <asandstrom2@eastlink.ca>
Date: Fri, 30 Mar 2012 23:45:15 -0300
Message-id: <4F766FBB.2070301@eastlink.ca>
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*

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

Received on Saturday, 31 March 2012 02:45:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:57:24 UTC