Re: Validating FO

On 21 January 2014 10:25, Tony Graham <tgraham@mentea.net> wrote:
> 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.

Not that Tony, but Chris perspective has often struck me as 'individual'.



>
> 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].

Which is no longer a reason to retain that as gospel? W3C members
are showing little / no interest in FO? Why retain that 'requirement'?

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

History isn't a reason for me.

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

It makes it a way of working used by Tony, no more?

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

Yes and yes. One way to achieve the second would be a ready means
of validation within the editor. An rng schema could provide that.


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

The red line is a means of displaying that information, not a method
of doing it.

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

Not with the current rules IMHO, or at least not without a very significant
effort?

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

Epub <> FO? Quite a different ball park.


regards


-- 
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk

Received on Tuesday, 21 January 2014 12:10:41 UTC