Re: Another viewpoint on validation

On 09.04.2012 12:01:50 Dave Pawson wrote:
> On 9 April 2012 10:53, Jeremias Maerki <dev@jeremias-maerki.ch> wrote:
> > 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
> 
> Good point.
> 
> Taking the Linux approach, what are the constituent parts?
> 
> Validation of an fo file to the rec (somehow)
> formatter X does A not B.... or should that be more specific?
>  E.g. Does formatter X do everything in MY fo file?
> interop.... Is this flogging a dead horse? Waste of time?
> I'd prefer the conformance approach... somehow.

Not sure what you mean.

> 
> I certainly like the idea of a small number of single
> focus 'tests' or specs or whatever.
> 
> 
> >
> > 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.
> 
> Is that something we should address at the spec level? I.e. it isn't
> clear enough?
> Do we have sufficient input to do this?

Well, the above example is well-documented and unambiguous.

Another issue was the intentional breaking of property inheritance over
viewport/reference pair boundaries by most implementations. That was
clarified on the editor list but I doubt that implementations will fix
that because of that. Not sure that was addressed in the latest 2.0
draft.

So, I guess many things are not black and white. On the spec
interpretation side, improving the spec is likely difficult, but a test
suite can help a lot here.

> >
> > 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.
> 
> Yes, I too think this is doable, with much work and would benefit
> the users, eventually the formatter writers.
> 
> 
> >
> > 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.
> 
> If we get to that stage, it is time to look at clarification of the spec.

I guess some feedback from the test suite back into the spec is possible
but not easy and digs into the limited resources of the spec writers.



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 11:06:46 UTC