Re: Another viewpoint on validation

On 09.04.2012 13:57:52 Dave Pawson wrote:
> On 9 April 2012 12:06, Jeremias Maerki <dev@jeremias-maerki.ch> wrote:
> > On 09.04.2012 12:01:50 Dave Pawson wrote:
> 
> >>
> >> 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.
> 
> If I never use feature X from XSL-FO, I don't care if it is covered by
> my formatter?
>  I want to answer the question,
> for this fo file, does this formatter process all the .fo content.

Got it. So, if you can't use the formatter itself to do that check, the
formatter/implementor must provide some sort of profile file describing
what the formatter can do and a separate validator product needs to
interpret that profile and apply it against the given FO. Big task.

> 
> 
> >
> >>
> >> 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.
> 
> I'm sure there are others that are debatable?

Of course. ;-)

> >
> > 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.
> 
> Another issue which could be addressed by a spec change?

Sure, but that doesn't mean that implementors change their formatters
because that might break their client's stylesheets. Well, that's
assuming the clarified interpretation is put into the spec and it's not
adjusted to the more enduser-oriented interpretation.

> 
> >
> > 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.
> 
> With spec changes as a fallback for final resolution?

Sure, but I'm sure having a public test suite would allow a quicker
resolution than updates on the spec.

> 
> >>
> >> 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.
> 
> Note that now 'we' are the spec writers?

Uhm, I thought it's the W3C WG that make up the actual spec writers, not
the PPL community group. I can't currently commit enough time to join
the XPPL WG.


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 12:13:05 UTC