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

Hi Erik,

Fair enough.  I was trying to see if there was an easy way out of the 
issue of wanting mip attributes to apply only to the control they're on.

So, it seems we're back to the issue of having just UI control that we'd 
like to imply an instance in a model, and we'd like to have MIP attributes 
on the controls to imply binds on the instance data in that model.  This 
way, one *could* translate to a canonical XForm easily.

Next, it sounds like we want the MIP attributes on the controls to behave 
consistently if one expresses either an instance or instance in a model, 
i.e. that they would still imply the same binds.

This leaves the MIP attributes unavailable for use in "styling" individual 
controls. 

That being said, the MIP attributes still seem usually to be the wrong 
ones if one means to affect a control rather than the data.  This is 
because not all of the MIP attributes make sense.  The ones that do seem 
to be useful at the control level are readonly and relevant, so I wonder 
if we need new attributes called control-readonly and control-relevant.

Frankly, we already seem to have the fundamental notion of 
"control-relevant" built into XForms because this is how we are letting 
the UI layer groups impose non-relevance on their contained controls, 
overriding the model level relevant MIP-- including overriding the 
inheritance system built into model level inheritance.  What do you think 
about this concept?  And if you like, then where do you think it goes 
(1.2/2.0)?

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





Erik Bruchez <ebruchez@orbeon.com> 
Sent by: public-forms-request@w3.org
02/13/2008 10:01 PM

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

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







John,

Interesting, I had not realized that you intended this to work this 
way only with an implied instance.

Now your suggestion opens some possibilities. I am a little concerned 
about consistency: it might be confusing for attributes to cause 
different behaviors if there is a model or not.

And then what would we do with those MIPs (required, constraint) which 
probably do not make much sense outside of the model?

-Erik

On Feb 5, 2008, at 9:37 PM, John Boyer wrote:

>
> 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/
>
>
>

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