- From: Mark Birbeck <mark.birbeck@x-port.net>
- Date: Tue, 29 Aug 2006 00:33:37 +0100
- To: "Klotz, Leigh" <Leigh.Klotz@xerox.com>
- Cc: www-forms@w3.org
Leigh, On 29/08/06, Klotz, Leigh <Leigh.Klotz@xerox.com> wrote: > For the record, I'm not opposed to Mark's proposed process...I just want > to have a process so we can follow it when we add new attributes in > later versions. I propose the XSLT 2.0 rules, but surely it's possible > to work out others. For example, the XSLT rules would not allow > toggle/@case because it's an IDREF. Clearly that is of value, but we > have to weigh the cost of the rules against the value of the result. But I think we need rules that fit our processes--the XSLT rules fit with XSLT processing. I'd wager that no implementer would have a problem with making just about any attribute into one that supports AVTs, other than those used in MIPs. This is due to the XForms processing model. In addition, having AVTs in any attribute that is processed before all the instances are ready is also a problem, and that would cover: * @src (as Joern pointed out); * @ev:event and @ev:observer (as Erik hinted at), but not @ev:handler; * any XLink construction where the @actuate is on load; * XInclude references... ...and so on. I don't think this going to be too problematic to sort out, and this only amounts to two rules: 1. No AVTs in MIPs. 2. No AVTs in attributes that are evaluated before the DOM load event. This is still simple--I agree with you that we need rules--but it also has the merit of being easy to define in a way that ensures compatibility with host languages. (At the moment it's XForms-centric.) Regards, Mark -- Mark Birbeck CEO x-port.net Ltd. e: Mark.Birbeck@x-port.net t: +44 (0) 20 7689 9232 w: http://www.formsPlayer.com/ b: http://internet-apps.blogspot.com/ Download our XForms processor from http://www.formsPlayer.com/
Received on Monday, 28 August 2006 23:33:55 UTC