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 10:15:12 +0000
Message-ID: <CAEncD4c9jhybGky5hdZhiTw3_0gsMZCh0+_P-a_QUyuKoKhFLA@mail.gmail.com>
To: public-ppl@w3.org
On 20 March 2012 09:37, Tony Graham <tgraham@mentea.net> wrote:

>>> 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?
>
> >From XSL 1.1, Section 5.9, "Expressions" [1]:
>
>   All property value specifications in attributes within an
>   XSL stylesheet can be expressions. These expressions
>   represent the value of the property specified. The expression
>   is first evaluated and then the resultant value is used to
>   determine the value of the property.

No editor / validation scenario would support this Tony?
  Hence I regard that as out of scope.

>>>> 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.
>
> That would depend on which 'we' we be.  From the XSL 2.0 requirements,
> Section 11.6, "Compatibility" [2]:

I don't see that as binding any longer? Do you?



>> For colour, I'd suggest it is likely to be the 0.01% that would feel the
>> effect.
>
> I don't know the details of your issues with the 'color' syntax.  Would
> you be able to start a new thread and/or wiki page about that?

I think this thread is leading to higher level issues, e.g.
backwards compatibility, binding of W3C requirements etc?
Before moving to details, perhaps we could address those?



>
> The XSL-FO 2.0 draft adds additional color functions for compatibility
> with SVG [3].  What about those?

My view? Ignore them until we have a working Schema.


>
>>> Additionally, CSS users outnumber XSL-FO users a lot.

>> I don't see the mandate there? "To make things easier "
>> How would you define that?
>
> This isn't so much about making things easier as not making them harder.
> Mohamed started the thread about whether we're about paginated layout [4]
> or just about XSL-FO, and it seems to me that moving the specs further
> apart isn't going to help meld them together.

I haven't mentioned that. Do you infer that?


>
>> IMHO having a complete schema to validate (even within
>> a syntax directed editor) would make things much easier?
>
> As it was explained to me, XSL-FO defies all known schema technologies by
> doing things like allowing just about any property on just about any
> element because they wanted to make things easier for people rather than
> thinking firstly about how to fit things into a schema.  So ideas of
> what's 'easier' can often differ.

My view again (I can offer no other). As I think you are aware, I and others
believe this to be silly and not a help at all. It certainly doesn't make
'things easier' for an author.

I would support a relax NG schema which any processor may support
some/all. That would help authors through the miriad of options
that the above para makes feasible.


regards

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

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 20 March 2012 10:15:47 GMT