- From: Tony Graham <tgraham@mentea.net>
- Date: Tue, 20 Mar 2012 14:12:16 -0000 (GMT)
- 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"> <xs:annotation> <xs:documentation> An XPath 2.0 expression. </xs:documentation> </xs:annotation> <xs:restriction base="xs:token"> <xs:pattern value=".+"/> </xs:restriction> </xs:simpleType> 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". Regards, Tony. [1] http://www.w3.org/TR/xslt20/#schema-for-xslt
Received on Tuesday, 20 March 2012 14:12:46 UTC