Re: Validating FO

On Mon, January 20, 2014 11:00 am, Dave Pawson wrote:
> On 20 January 2014 09:54, Tony Graham <tgraham@mentea.net> wrote:
>> XSL-FO 2.0 was following SVG in defining its color functions [2].  Chris
>> Lilley came to a F2F specifically to talk about colour/color, and we
>> decided to align with what SVG had.
>
> So Chris Lilley says it's OK... Mmm

Seriously?  On behalf of everybody involved at the time, thank you for the
vote of confidence in our mental faculties.

The XSL-FO 2.0 requirements document [1] had for the previous few years
contained:

   9.6 Color support

   Improved color support including things that SVG Print does.
   For example add device-specific CMYK color. Add support for
   the color names that are supported in SVG. Fills/Shading/Vignettes

So it wasn't that we did something because Chris said so, we didn't do
what we'd intended until we'd talked it over with one of the authors of
that spec [2].

You can argue against commonality between W3C specs or against the need of
some people for better colour control, but please look into the possible
reasons before you again imply that decisions were made without thinking
about them just because somebody said so.

>>>   Mixing lengths is another irregular property set.
>>
>> I do it quite often.  From a stylesheet that I happened to have open
>> right
>> now:
>
> That doesn't make it right Tony?

In the absence of it being wrong, yes, it does.

>> Just because there's more to the property values than you can usefully
>> assert with Relax NG doesn't mean that it's wrong.
>
> No. But one thing I would like to do for users is make it easier to use?
> And in this aspect, ease of validation would make it easier to use?
>   "What property can I use here" is an oft heard question IMHO
> regards

Which, IMO, points to a need for better training materials and better
editor support.

XSLT users are now used to the squiggly red line (or similar) from when
their XML editor parses the XPaths in their XSLT attribute values and
warns them of mismatched parentheses, unknown variables, etc., and users
wouldn't be happy if their editors just went back to indicating which
attributes are and aren't allowed on a particular element.

A properly FO-aware editor could, for example, highlight expected,
inherited, and non-inherited properties in different colours and do the
XSLT-editor-like parsing of the property values to bring the benefit of
the squiggly red line to FO, too.

In terms of validation outside the editor, thousands of people manage to
run epubcheck [3] on their EPUB files to do a multi-stage check of every
aspect of the EPUB.  If one schema can't express everything about FO
files, then perhaps users need a multi-stage checking mechanism rather
that whittling FO down to what can be expressed in a particular schema
language.

Regards,


Tony.

[1] http://www.w3.org/TR/xslfo20-req/#N67097
[2] http://www.w3.org/TR/SVGPrint/
[3] https://github.com/IDPF/epubcheck

Received on Tuesday, 21 January 2014 10:26:11 UTC