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

Re: Workflow - on the wiki

From: Dave Pawson <dave.pawson@gmail.com>
Date: Tue, 20 Mar 2012 07:19:06 +0000
Message-ID: <CAEncD4cBizgMP9_VKqdY9Af8EGuzh4Zp+xoO=mfzzN+dWphp=w@mail.gmail.com>
To: public-ppl@w3.org
On 19 March 2012 20:33, Tony Graham <tgraham@mentea.net> wrote:

> IIRC (and Liam or Jirka may be able to confirm this), a lot of what people
> said about 'validation' had to do with wanting to confirm which properties
> are supported by which (or a particular) XSL-FO processor.

Puzzling, since that information is available.


>
>> There are. Have you looked at it Jirka?
>> For 'the hard ones' they use a content model of text.
>> That's where I came unstuck. This happens in a number of areas.
>
> Many properties' values can be expressions that need to be resolved before
> you can work out if you have an allowed value.

 I don't understand this statement Tony?

>
>> A very good start, but (my view) it's the spec that needs simplification
>> rather than asking the grammar to catch up?
>>
>> border-start-color.attr = attribute border-start-color {  text |
>> expr.datatype }
>> expr.datatype = xsd:normalizedString { pattern = ".*\(.*\).*" }
>>
>> A start, but lots more needed for validation using this grammar?
>
> You haven't explained where this grammar comes from, but 'expr.datatype'
> would seem to be an attempt to accept expressions without evaluating them.

It's from the RenderX schema, rng.


>
>> I haven't used folint.xsl sufficiently to comment.
>> I could see some combination (schematron like), for the nasty ones?
>> I'd prefer to simplify the requirement, move away from the CSS definition
>> approach to these nasty ones, to provide a grammar for validation.
>
> But how do you do that without breaking backwards compatibility?

You don't. We have no such obligation Tony.
For colour, I'd suggest it is likely to be the 0.01% that would feel the effect.



>
> Additionally, CSS users outnumber XSL-FO users a lot.  When one of the
> themes from the XML Prague 2012 conference proper turned out to be the
> need to make things easier/acceptable for web developers, if XSL-FO has
> restrictions that aren't in CSS, I don't see that it would help people
> move between the two.

I don't see the mandate there? "To make things easier "
How would you define that?

IMHO having a complete schema to validate (even within
a syntax directed editor) would make things much easier?


regards

-- 
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk
Received on Tuesday, 20 March 2012 07:19:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 20 March 2012 07:19:36 GMT