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

Re: Workflow - on the wiki

From: Tony Graham <tgraham@mentea.net>
Date: Tue, 20 Mar 2012 14:12:16 -0000 (GMT)
Message-ID: <24020.>
To: public-ppl@w3.org
On Tue, March 20, 2012 10:15 am, Dave Pawson wrote:
> 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.
>> >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.

Then we have to agree to disagree.  Other people will have to chime in
here since we're unlikely to change each other's opinion.

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

I see backwards compatibility as hugely important for any software or file
format, with or without a requirements document.  Since we fundamentally
disagree on the worth or otherwise of shoehorning XSL-FO into what can be
expressed today using RELAX NG, I haven't seen sufficient justification to
tell any user "Sorry, you'll have to adjust your existing
stylesheet/processing/output before you can use anything new in XSL-FO."

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

I don't see it that way: yes, there can be reasons for breaking backwards
compatibility, but, no, I don't see diving into a RELAX NG schema as
sufficient reason.

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

The (non-normative) XSD for XSLT 2.0 [1] models an XPath 2.0 expression as:

<xs:simpleType name="expression">
      An XPath 2.0 expression.
  <xs:restriction base="xs:token">
    <xs:pattern value=".+"/>

The value that XSLT users get from the squiggly red line in editors like
oXygen (or, for RELAX NG compact syntax, the red background from
`flymake-mode' in Emacs) isn't just from there being a schema, it's also
from the editor software parsing things at a finer granularity than the
schema expresses.  I'd happily support calls for editor software to do
better at parsing XSL-FO attribute values, and if there was an open-source
XSL-FO expression parser plugin for oXygen or any other editor I'd
probably contribute to it, but I don't see making XSL-FO fit RELAX NG as
being the solution to the statement "users want more validation".



[1] http://www.w3.org/TR/xslt20/#schema-for-xslt
Received on Tuesday, 20 March 2012 14:12:46 UTC

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