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

Hi Erik,

>> 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.
> Whether it is an change or not is debatable, unless we know the
> original intents of whoever designed the readonly MIP. Apparently, not
> all the consequences were thought out, as I tried to explain in my
> other message.

I think you may be stretching things a bit to say that John's proposed 
rewording is not a change :-) The intent of the new wording is clearly
quite different to both the original text and with a number of 1.0 
implementations, which after all are interpretations of that text.
> I don't really disagree with the fact that "read-only" may mean two
> different things. I have myself argued that the definition of "empty",
> for example, was pretty useless from a user's perspective, and it was
> countered to me that it made sense from a programmer's perspective. My
> conclusion is that maybe we need two types of "empty" (wrt the
> required MIP).

Well, if we have different kinds of read-only that we need to allow 
for, then let's capture them. 

> But as much as we would like to imagine people writing models and
> other people writing UI's using those models, I have yet to see that
> division of work really happen. This reminds me very much of such
> divisions, very much theoretical, established in specifications such
> as JavaServer Faces. It's as if five different people could work on a
> user interface at the same time. I am not saying this never happens,
> but I have yet to see it. I personally have only had use cases where I
> wanted to prevent the *user* to change values, but not my own
> *actions*. This may purely stem from the fact that we at Orbeon
> usually write both models and UI. I would expect this situation to be
> very common based on what I have seen from our users and customers.

It would seem that my experience of using XForms has been somewhat 
different to yours. Origo, the organisation I worked for until earlier 
this year, produces XForms models as a useful adjunct to XML schemas, 
for use across the UK Life Assurance Industry. In this case there are 
potentially dozens of consumers of each model, and if an Origo 
architect has specified conditions under which a node value is 
read-only, then they really did mean read-only in the sense set out in 
the 1.0 spec.

Similarly, PicoForms has customers working on large, complex projects 
who also make the architectural divide between model and view into a 
real, organisational one. Again model authoring is more akin to schema 
authoring, quite divorced from coding the forms that consume schema and 

I honestly don't see this way of working as being that unusual, any 
more than the scenario you describe.

But even if that were not the case, I do think it useful to be able to 
define read-only such that it is impervious to actions. After all, a 
user may only be able to ever change a value by triggering an action, 
perhaps quite indirectly. Conceptually I am not so sure that it matters 
anyway how the attempt at changing value is achieved. One could argue 
that an input is just a user triggered setvalue. 

I also agree that it is useful to be able to disable, with varying 
degrees of specificity, value changing things (controls/actions/script) 
bound to particular nodes, even when the model says something is 
> It would be nice to protect a form author from his own mistakes, but
> then we have to think about the cost of it, at least the cost of
> implementing it properly.

Indeed, let's make sure we do it properly. Both you and Nick have 
pointed to holes that emerge in 1.1, for example. Let's document them 
and see how best to fill them.
After all, read-only is not just protecting the view author from 
mistakes, it is expressing the intent of the model author.
>> 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 am not sure I understand this question. But from an eventing
> perspective, we do dispatch all MIP-related events to the UI, not to
> the model. That's probably because they are actually much more useful
> in the UI.

Isn't it so that the UI, or indeed anything else, bound to a model can 
accurately reflect the model's state?

I was trying to ask (if we accept the new text), whether other MIPs 
than read-only should only be honoured by form controls? Why shouldn't 
a form author be able to code around a calculate for example? It would 
be useful to be able to switch on and off a calculate MIP, or define 
three or four for the same node. Same with type. The number of times 
when I have wanted to change the type of a node depending on how the 
user is getting on with a form. Is it a date, or is it a string, so 
that the user can leave themselves a note to remind them who to ask for 
the right date when the come back to it?  

> The XForms model, while a model in an MVC architecture, remains, for
> me, the model for a user interface. I am sure we can imagine other
> useful uses for it, and we should probably make it as independent from
> the UI as we can reasonably do so, but I fail to see a great future
> for the backplane. Heck, we better make sure that XForms has a great
> future, and there is a whole lot to do still to make that happen.

I agree that the XForms model is good for binding to UIs, but I can't 
believe you really have used instances for nothing more than creating 
UI views. What about SOAP envelopes, etc. Surely the model is above all 
else an application context, that for reasons of completeness includes 
bindings to a logical UI, so that if you need to you can allow people 
to interact directly with XML instances. After all, it is a really 
important use case ;-)

I have to say that since joining PicoForms the "forms" I have worked on 
are almost exclusively applications, that, whilst they involve 
interaction with structured data, would hardly be described as 
electronic forms. In fact, thinking about it, the "view" has almost 
never been a view of an XML document that a user needs to edit, but 
rather a representation of an HTTP query string, or something else that 
has an indirect relationship with one or more XML instance.
> This opinion is partly motivated by the fact that, as a working group,
> we have only limited manpower, and I would much prefer seeing all WG
> members work on making XForms a great forms solution rather than
> dissipating energies in multiple directions at a time.

I would humbly suggest that even within the confines of the WG there 
are as many views of what constitutes "a great forms solution" as there 
are WG members. Luckily there is plenty of overlap :-) But diversity is 
definitely a good thing, even if it can be time consuming. 

All the best


Received on Thursday, 23 August 2007 16:43:11 UTC