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

Re: Another viewpoint on validation

From: Dave Pawson <dave.pawson@gmail.com>
Date: Mon, 9 Apr 2012 12:57:52 +0100
Message-ID: <CAEncD4eC3RePeNMfFSwYGSuK2UGsH5hYUHviV2PpntuZxqan6w@mail.gmail.com>
To: public-ppl@w3.org
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?

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

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