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


PicoForms processors also honour read-only by blocking the setvalue 

I agree with Nick, the proposed change to read-only should not be 
undertaken lightly, and I would prefer it not to be undertaken at all. 

Surely if a model author (as opposed to form author - they may not be 
one and the same) wants to specify the conditions under which a node is 
read-only, they will simply want the node to be read-only. They might 
not even know what class of application will bind to the model - there 
may never be a form involved.
If a form author finds that there are circumstances under which they 
need to prevent a user from changing the value of a node that according 
to the model is actually writable, then that is an entirely different 
matter, and it is a shortcoming of XForms that there is no convenient 
way to achieve this other than by messing directly with the model. As 
Nick says, XForms needs its own UI centric method for disabling form 
controls bound to particular nodes (or perhaps just disabling 
particular controls  - you may have several controls bound to the same 
node and want to just disable one or other of them in particular 

And another thing. Why should read-only be any different to calculate, 
or type? Are we saying that some MIPs only relate to the UI? 

I suppose I don't really see the model as belonging to XForms any more 
than it belongs to any other XML vocabulary. The model is a useful 
construct that allows me to define sets of related data structures and 
their relationship as a unit to the outside world. It actually makes me 
uncomfortable every time I have to add any UI centric code to a model. 
Or is that just my itchy underwear?

I guess what I really want is a model that is my data model, that 
doesn't know or care what consumes it, just so long as it is consumed 
on its own terms (all MIPs honoured, thank you very much), and a 
separate, form model that provides the local context. There I can play 
merrily with all my UI toys, safe in the knowledge that the data model 
to which my form binds is looking after its own thing.

So, if the XForms model is the XForms model, it needs more UI centric 
functionality and by-the-way, can someone please invent this other 
"back-plane-model-thingie" that we need;


if the XForms model is the "back-plane-model-thingie", can we please 
invent another, UI centric model for use with forms?

I don't mind which way round it happens, but it would be great to have 
clarity and consistency, so we all know what we mean by "the XForms 
model" :-)

All the best


> 6.1.2 The readonly Property
> Previously section 6.1.2 The readonly Property[1]  clearly stated that 
> "When evaluating to true, this model item property indicates that the 
> XForms Processor should not allow any changes to the bound instance data 
> node." And I know for certain that Chiba, the Firefox extension,… block 
> the setvalue action from changing read-only content. I know that it is 
> hard to enforce this if you provide direct access to the DOM through 
> script. But I don't think we should sacrifice the nice separation in our 
> MVC architecture, the model needs to be the one that enforces the 
> read-only property both to the View (the UI) and the controller (the 
> actions). I know that the previous wording needs some tweaking because it 
> doesn't say if a submission is allowed to replace inside read-only 
> content, and if it isn't allowed what exception is dispatched. But it 
> clearly states that no changes are allowed, we should think twice before 
> changing this. It breaks backwards compatibility, is counter intuitive (at 
> least for me) and in my personal view breaks the principle that data 
> integrity is enforced by the model. If we really want a UI read-only 
> attribute it should live in the UI and be an attribute on the form control 
> and not on the binding in the model.

Mark Seaborne
Senior Standards Architect
tel: +44 131 2080031
mobile:  +44 787 2180215

Received on Wednesday, 22 August 2007 08:03:15 UTC