Re: Big update to XForms 1.1 spec; Ready for your review


I think there are some good points that came up in this
discussion. It's good to see that this is causing more people
(finally, I should say) to react to what's going on.

But I am still not convinced by Nick, Mark and Joern's arguments!

Consider this: we say with the @constraint attribute that the value of
an element or attribute must satisfy certain conditions, right? Yet,
will we prevent xforms:setvalue from setting a value that does not
satisfy this condition? What about @type? What about @required?

The logic I have heard so far seems to say that since the readonly
constraint is expressed, it cannot be violated by setvalue.

But if I follow this logic for the other MIPs, shouldn't we say that
setvalue cannot set a value because it doesn't match the type or
constraint set with @type and/or @constraint? After all, the form
author attempted to enforce a constraint here, and setvalue certainly
would violate it.

Do implementations actually prevent setvalue to set values that
conflict with those other constraints?

I reckon that the spec says that a read-only node shouldn't be allowed
to be modified, and I don't remember reading anything similar for the
other properties. But whatever the spec actually says at the moment, I
just wanted to point out above that the constraints expressed in
XForms are in general not rigid from the point of view of the
actions. As I understand it, they can set value that conflicts with a
type, violate a constraint, and clear a required value.

And I think it is a good thing, because otherwise yes, we enforce
constraints in the model, but we also remove a lot of flexibility in
the model. If this is right, this tells me that there is a case to be
made to treat readonly in a similar way.


Orbeon Forms - Web Forms for the Enterprise Done the Right Way

Received on Friday, 24 August 2007 13:24:35 UTC