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

I strongly agree with mark here. One of XForms strengths is its
clean model-centric design and separation of interaction specific
bits from the model; I know it's tempting to break this,
especially given some of the Xforms alternatives, but I suspect
that watering this piece down will end up losing whatever value
remains in XForms. 

Said differently, if XForms tries to please everyone, it will
please no one.

Mark Seaborne writes:
 > 
 > 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 
 > model.
 > 
 > 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 
 > read-write. 
 >  
 > > 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
 > 
 > Mark
 > 

-- 
Best Regards,
--raman

Title:  Research Scientist      
Email:  raman@google.com
WWW:    http://emacspeak.sf.net/raman/
Google: tv+raman 
GTalk:  raman@google.com, tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc

Received on Friday, 24 August 2007 17:25:14 UTC