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=rssdwNick_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