Re: Add model item properties to UI level (Action 2008-01-23.2)

Hi Nick,

In a telecon discussion, the working group already agreed to most of what 
you said below and gave you the action item to write the strawman proposal 
for further discussion.

In the telecon discussion, the working group agreed to being able to put 
MIP attributes on controls as a way of specifying *model item* properties 
on the data nodes implied by the UI controls bearing those MIP attributes.

When doing an implied data model from the UI, there is simply no way in 
general to tell the difference between a MIP attribute and a UI control 
attribute if the same name is used. It seems fair to say that calculate on 
a UI control is a MIP and not a UI-level property.  At first, readonly 
seems a clearer example of a control-specific property, at least until you 
remember that we have a name for a readonly input-- output. 

However, I notice that you end by proposing that the UI layer MIPs should 
just be regarded as implicit binds.  I think this version is what the 
working group agreed to because it does not fundamentally shift the XForms 
processing model in 1.2. 

You can declare a MIP on a UI control, and it applies to the data.  If the 
data is implied by the UI, then every control gets a separate datum, so it 
the applicability of the MIP to data is a concept we espouse that only 
comes into play when you translate to a canonical XForm that has a 
declared data model.  At that point of conversion, the MIP attributes on 
the controls are moved up into binds anyway.  This is the simplification 
on-ramp, and seems a separate issue from having UI-level MIP attributes 
once you have a declared data model.

As a separate issue, you're saying that you want to have UI level MIP 
attributes as a quick and dirty way of adding MIPs that imply binds 
because this will allow the UI designer to add MIPs beyond those created 
by the data model author.  This seems OK if we could look at it as an 
implicit version (another on-ramp) for the nested model concept that 
Charlie and Mark are working on.  You may recall the telecon in which the 
nested model was proposed as a way of letting the UI designer "subclass" 
the data architect's model by wrapping a model around it, like this:

<model id="UserInterfacePerson">

     <model id="DataPerson">
            instances, binds, submissions
            maybe an xforms-model-construct-done handler
    </model>

    more binds for constraints, relevance, readonly etc.
    possibly more submissions for web services that enrich the fill 
experience
    possibly an xforms-ready handler
</model>
 
In fact, the UI person's design experience could even build up the model 
without their really being terribly aware of it.  The UI person in a 
visual design experience would gesture at a UI control and say "make it 
readonly" and the design experience would add a readonly bind to the UI 
person's model.

A cornerstone of this seems to be the ability to attach multiple MIPs of 
the same kind to a data node, which you and Leigh are also working on. For 
example, it seems clear that the default combinator for multiple readonly 
MIPs should be OR (if any of the MIPs says make it readonly, then it's 
readonly).  The default combinator for relevant MIPs seems as though it 
should be AND (all relevant MIPs must be true; if any are false, then the 
data node is not relevant).  The default combinator for constraint and 
type also looks to be AND, the default for required should be OR, and the 
default for calculate should be an error.

Cheers,
John M. Boyer, Ph.D.
Senior Technical Staff Member
Lotus Forms Architect and Researcher
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed: 
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw





Nick_Van_den_Bleeken@inventivegroup.com 
Sent by: public-forms-request@w3.org
02/01/2008 08:47 AM

To
"public-forms " <public-forms@w3.org>
cc

Subject
Add model item properties to UI level (Action 2008-01-23.2)







As most of you know there are two main reasons why I (and I hope, we) want 
to allow model item properties on form controls : 

   1. For the easy of authoring when creating simple forms and you are 
using an implicit instance. When you created your form using lazy creation 
but want to add some model item properties (for example types, 
constraints, ...) it would be nice that you just could add those model 
item properties to the form controls without the need to create a model 
element nor a bind element. 
   2. When you have a separate model and form UI designer there are cases 
where the UI designer can add extra model item properties to certain 
controls that don't need to be enforced by the model (for example extra 
constraint, stricter type, UI control is read only) 

Both these use cases could be solved by creating an implicit model with 
implicit binds. Treating them as implicit binds will allow a smooth 
transition when the need arises for explicit binds (e.g.: bind the id-type 
to all attributes with name id, ...), we can then just merge the implicit 
and explicit binds, the question about if it is allowed and what happens 
when the same MIP is specified multiple times for the same node, should be 
treated separately I think because the same problem can arise when only 
using explicit binds[1]. 

I can write up some spec ready text for this but I think it would be 
better to talk about at the f2f and see if people agree with those 
implicit binds and that the same MIP specified multiple times on the same 
data node is another feature (this feature may be a requirement to solve 
use case 2). 

Regards, 

Nick Van den Bleeken  -  Research & Development Manager
Inventive Designers
Phone: +32 - 3 - 8210170
Fax: +32 - 3 - 8210171
Email: Nick_Van_den_Bleeken@inventivegroup.com 

[1] : 
http://www.w3.org/MarkUp/Forms/wiki/Same_model_item_property_on_the_same_node
Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer