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/

Received on Thursday, 14 February 2008 06:01:53 UTC