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

Re: Workflow - on the wiki

From: Tony Graham <tgraham@mentea.net>
Date: Mon, 19 Mar 2012 20:33:23 -0000 (GMT)
Message-ID: <26181.>
To: public-ppl@w3.org
On Sun, March 18, 2012 8:43 am, Dave Pawson wrote:
> On 18 March 2012 02:38, Arved Sandstrom <asandstrom2@eastlink.ca> wrote:
>> What Dave mentioned about grammar-based validation jibes with my
>> impressions from many years ago; honestly I'd have to revisit the
>> problem myself before committing an opinion. :-) Having said that, it
>> strikes me that if you've got folks in Prague at XSL 2012 saying that
>> XSL validation is a problem, surely a number of them must have tried the
>> RenderX and AH products, so what are the outstanding deficiencies with
>> those?

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.

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

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

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

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.


Received on Monday, 19 March 2012 20:33:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:57:24 UTC