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

Hi Erik,

Whether or not I agree with everything you said below may be rendered 
academic by considering if there is a way to rationalize the two 
positions-- without creating an inconsistency between how readonly and 
relevant are treated versus how calculate, constraint and type are 
treated.

I'd like the MIP attributes to imply MIP properties.  You'd like MIP 
attributes to (sometimes) apply to the control.  But I only need the MIP 
attributes to imply MIP properties in the "implied instance" authoring 
mode.  I think we can detect this mode because the author is likely using 
the name attribute rather than the ref attribute.  A conversion to 
'canonical' XForms would create a data model, move the MIP attributes to 
the model AND change the name attributes to ref.  Now, given a canonical 
XForm, if you attach to a control *any* attribute with the same spelling 
as a MIP attribute, then surely you mean to apply it to that control only.

What do you think of that?

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





Erik Bruchez <ebruchez@orbeon.com> 
Sent by: public-forms-request@w3.org
02/04/2008 02:15 AM

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

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







On Feb 2, 2008, at 7:33 AM, John Boyer wrote:

> As you saw in my note to Nick, readonly on input does not make sense
> because that's an output, and wanting an output to look like a 
> readonly
> input is a styling issue, not an XForms abstract UI issue.

This is not correct at all. An input control can *change* read- 
onliness over time. The approach you describe obviously does not work 
in that kind of situation because it would require that a control 
switch from being an input to an output and vice-versa. And even in 
the unlikely event that we made something like this possible (and 
really we would not!), this wouldn't be good either because the read- 
only input must keep an appearance that identifies it as an input, not 
an output, to the user, even though input is temporarily disabled for 
that control.

I think that it is a common user interface pattern to have input 
fields that switch from read-write to read-only and back over time so 
I guess I don't need to argue about that point.

So we really have an *input* control which happens to be displayed as 
read-only at some point because it has a property specifying that it 
is read-only. This is true whether you use a MIP or a UI property 
(UIP?).

I have even a better argument coming:

When we (strongly) argued about whether the read-only MIP should 
actually protect the XForms model's data from any external 
modifications, back at the Madrid f2f, I proposed a use case where the 
data in the model should be modifiable with <setvalue/>, but an input 
control bound to data had in fact to be read-only. This is a use case 
that makes sense if at a certain point, data entry is not possible by 
the user, but the instance data can change in the background, for 
example as a result of a series of actions or an instance replacement.

With the new semantics of the read-only MIP, this is hard to do: you 
have to somehow disable that MIP to change a value. This is one reason 
I was against the strong read-only MIP proposal, and I lost. BUT, IIRC 
it was suggested at that point that having the ability to have a read- 
only property on the control would be a solution to this problem.

Clearly, if the read-only property on the control creates an implicit 
bind, my use case is still not satisfied. While if it is just a UI 
property, then it is.

> Similarly, it makes no sense to attach relevant to a particular 
> control;
> if you want to hide a particular control, you can use the XPath 
> predicate
> trick in the UI binding, or more appropriately, style it to 
> display:none
> or visibility:off.  Again, per control properties like this look like
> styling to me, and should not be confused with MIP attributes.

I think that this conclusion is reached too fast.

Styling a control this way with CSS doesn't work: if you always want 
the control to be visible or hidden, sure, do that. But the reason I 
want to use XPath to control relevance is because that relevance can 
change over time.

And as I have said, the XPath trick is just that, a trick, and one I 
think we should move away from as fast as we can.

So we still end up with a non satisfactory solution to independently 
control the relevance of individual controls bound to a same node.

So I can only object to the first two arguments made above.

> Attaching constraint to a particular control and not meaning for it 
> to be
> applicable to the underlying data makes even less sense.  If you do 
> have
> two controls bound to the same data node, but you only attach the
> constraint to one control, then if you add bad data in the other 
> control,
> you are guaranteed to show invalidity in the control bearing the extra
> constraint.  What kind of user experience is that?
>
> For required, it similarly makes no sense to have one UI control 
> requiring
> data entry and another not requiring it for the same node of data. 
> The
> only way it makes sense is if you plan to sometimes hide the control 
> where
> the data is required.  But in that case, you're really setting up a
> *condition* on whether or not the data is required (it's the same
> condition that would show or hide the control that would bear the 
> required
> attribute).  So again, with proper use of the feature, you could still
> attach required MIPs to the controls and actually intend for the 
> attribute
> to be a *model item* property.

I agree that constraints and required properties are problematic. But 
do we *have* to have these two properties directly on controls?

I guess you will answer yes if you start with the a-priori idea that 
what you want to build are implicit binds, mainly for lazy authoring 
purposes.

But if like me you are more interesting in a simplified syntax for 
large forms, and in satisfying the use cases I presented above, then I 
don't think that there is a huge requirement for having these two 
properties directly on controls.

But if they really are needed, there may be some ways out. For example:

* Only those properties that clearly must impact instance data could 
create implicit binds, while read-only and relevant would behave 
differently.
* We could create new names for these two UI properties, and consider 
that they exist in addition to the current MIPs.

-Erik

--
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/