Re: Another viewpoint on validation

Aren't we touching multiple topics in this thread?
1. XSL-FO validation
2. XSL-FO spec coverage by individual implementations
3. XSL-FO interoperability between implementations

I agree with Arved that running an actual FO processor is probably the
best way to validate XSL-FO, even though there are interpretation
differences among the implementations. Many implementations have
a relaxed implementation of the spec: they often don't complain about an
empty table-cell, for example. As a result, many FO editors actually
produce non-conforming XSL-FO because their creators haven't read the
spec closely enough or just haven't run into an error message by their
favorite (or own) FO processor.

For spec coverage, we could probably develop an XML format here. But I
doubt that many implementors will participate here (think "exslfo"). I'm
sure that tooling around this could add some value: product comparison,
for example. But some implementors might not be interested to have that
done publicly. OTOH, it's obviously a big desire on the user side when
evaluating products.

Finally, interoperability improvements between implementations takes a
serious effort for a comprehensive, publicly available XSL-FO test suite.
But even with a test suite, it will be difficult to compare
interoperability and spec coverage.

Just my 0.05 CHF.

On 08.04.2012 23:38:12 Tony Graham wrote:
> On Tue, April 3, 2012 12:54 am, Arved Sandstrom wrote:
> > My first attempt seems not to have gone through...
> > On 12-03-31 03:23 AM, Dave Pawson wrote:
> ...
> >> >  As Tony noted, many users are interested in 'is featire X supported
> >> > by Y processor'
> > As am I. And "support" means that feature X is "validly" supported, that
> > is, according to spec. Maybe incompletely, e.g. processor Y doesn't
> > support all the properties (by spec) for a given FO, but you know that
> > the properties you can use on that FO with processor Y are correctly
> > implemented.
> >
> > This again gets back to what I'm saying. The available processors are in
> > fact all we've got and all we'll ever have, to do the real work. In the
> > case of FO or CSS the XML+XSLT combo is just phase one, producing the
> > input for the browser or the FO processor. But as users what we really
> > care about is the output of the browser or FO processor: people have
> > always cared more about what real web browsers do with
> > HTML/XHTML+JavaScript+CSS than they do in the theoretical validity of
> > the input.
> >
> > How many people actually validate their XHTML web pages before feeding
> > them to a web browser? I don't know anyone who does that. I never have,
> 
> They do when it's an EPUB and the web browser is the one built into the
> EPUB reader.  People get a lot of mileage out of using 'epubcheck'.
> 
> > and I've written thousands of web pages in dozens of web apps. So why
> > worry so much about validating XSL-FO before it feeds to an FO
> > processor? Let's just maybe concentrate on the processors as the source
> > of validity information.
> 
> If we go back to my memory of what was said at the Prague meet-up. people
> there did want to know that their XSL-FO would work with their XSL-FO
> processor *before* they went to the time and trouble of trying to make
> pages.  It seemed to be the knowing what was and wasn't implemented by an
> implementation that vexed them, rather than the differences between what
> the spec says and what an implementation produces.
> 
> And if you've already paid money for an implementation, or gone to the
> trouble of integrating a free one, then it probably doesn't matter so much
> that another implementation has a different interpretation of some
> properties or even has a different cross-section of supported properties:
> your first preference will be to work with what you have now rather than
> throw it away and buy a new processor.  And if you can find out when
> you're writing your stylesheet that the property you just used isn't
> supported by your processor, you'll feel a lot less stressed than when you
> don't know and the use of that property causes an error message from every
> page of a 100-page document.
> 
> Regards,
> 
> 
> Tony.
> 


Best regards,
Jeremias Märki
_________________________________________________________
Jeremias Märki, Software-Development and Consulting
Contact Information: http://www.jeremias-maerki.ch/contact.html
Blog: http://www.jeremias-maerki.ch/blog/

Received on Monday, 9 April 2012 09:53:48 UTC