- From: Jeremias Maerki <dev@jeremias-maerki.ch>
- Date: Mon, 09 Apr 2012 13:06:24 +0200
- To: public-ppl@w3.org
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