Re: Follow-up on issue #73

Hi Erik,

The resolution actually was to add @value and *not* remove ref, whereas 
the original last call comment from Steven was exactly your proposal.

So, just to be clear, this is not a new proposal.

Moreover, the contention you make below, that @ref is used to bind 
something to a single node, is not uniformly true in XForms.

In fact, it is ironic that one counterexample to your point is the very 
mediatype element on *upload*, with which we seek authoring consistency.

The ref is also used on metadata elements such as label, help, hint and 
alert *without* the imparting the behaviors you described for MIPs and UI 
eventing.  These things are only true of *form controls* that use a single 
node binding.

Other easy counterexamples come from the actions, including setvalue, 
message and load.  Then there is submission, too!

The sum total of these serve to illustrate that by no means is it correct 
to say that ref can only be used when you want MIPs or want to write to a 
node, which should address your objections below, except the last.

Regarding your last point, the fact that output/mediatype can be used in 
other cases besides usage in conjunction with upload/mediatype is 
precisely why everyone agreed to *add* the value attribute as an 
alternative.

John M. Boyer, Ph.D.
STSM: 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





Erik Bruchez <ebruchez@orbeon.com> 
Sent by: public-forms-request@w3.org
06/27/2007 11:25 AM
Please respond to
ebruchez@orbeon.com


To
public-forms@w3.org
cc

Subject
Follow-up on issue #73







All,

Following today's call regarding this issue:

http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Controls?id=73;user=guest;statetype=4;upostype=-1;changetype=-1;restype=-1


I agree we should add the @value attribute.

My opinion is that we should in addition remove the @ref attribute.

The @ref attribute is used to bind "something" to a single node. Such
bindings are useful when:

   1. You need to obtain MIPs from said node.
   2. You need to write to a node.

It makes sense for xforms:output to have @ref, because xforms:output
may use the MIPs of its single-node binding.

Likewise, it makes sense for xforms:upload/xforms:mediatype to have
@ref, because it writes the mediatype value to the node.

But the xforms:output/xforms:mediatype is a different beast. In my
opinion, we introduced nested elements in XForms 1.1 as a stopgap
measure in the absence of attribute value templates (AVTs), which I
think are the right way to implement dynamic attributes.

Even if you disagree with that last point, the fact remains that we
introduced such nested elements to add dynamicity to attributes which
were otherwise static (like xforms:submission/@action|@resource). We
always obtain a string value from an attribute, and so do the matching
nested elements that complement them.

It seems to me that using @ref on such nested elements that complement
attributes is a use of the @ref attribute which is inconsistent with
other uses in XForms.

The argument that it parallels xforms:upload/xforms:mediatype/@ref is
not enough for me, especially since there are many use cases where you
use xforms:output/@mediatype without using xforms:upload.

Best,

-Erik

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