Re: Workflow - on the wiki

On Tue, March 20, 2012 7:19 am, Dave Pawson wrote:
> 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.

Not all in one place (AFAIK), and certainly not within a syntax-directed
editor.

The discussion at XML Prague 2012 is largely why I put 'compatibility
matrix' on the wish-list.

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

So these are all valid:

 - page-width="8.5in div 2"

 - start-indent="body-start() * 1.5"

 - background-color="from-table-column(color)"

   (Valid only within a fo:table-cell.)

 - writing-mode="from-page-master-region()"

   (Currently only usable with 'writing-mode' and
   'reference-orientation'.)

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

Okay, thanks.

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

   Existing XSL-FO documents should still be supported
   unchanged by XSL 2.0 processors.

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

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

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

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.

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

Regards,


Tony.

[1] http://www.w3.org/TR/xsl11/#d0e5032
[2] http://www.w3.org/TR/xslfo20-req/#N67203
[3] http://www.w3.org/TR/xslfo20/#expr-color-functions
[4] http://lists.w3.org/Archives/Public/public-ppl/2012Mar/0005.html

Received on Tuesday, 20 March 2012 09:37:37 UTC