Re: Another viewpoint on validation

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.



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

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


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



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


regards

Received on Monday, 9 April 2012 11:58:21 UTC