W3C home > Mailing lists > Public > www-forms@w3.org > August 2006

Re: url params et al

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Tue, 29 Aug 2006 00:33:37 +0100
Message-ID: <640dd5060608281633k24d47151h166cc3f18ccc3779@mail.gmail.com>
To: "Klotz, Leigh" <Leigh.Klotz@xerox.com>
Cc: www-forms@w3.org


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



Mark Birbeck
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
Received on Monday, 28 August 2006 23:33:55 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:18 UTC