W3C home > Mailing lists > Public > public-forms@w3.org > June 2007

Follow-up on issue #73

From: Erik Bruchez <ebruchez@orbeon.com>
Date: Wed, 27 Jun 2007 20:25:56 +0200
Message-ID: <4682ABB4.2060209@orbeon.com>
To: public-forms@w3.org

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/
Received on Wednesday, 27 June 2007 18:26:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 October 2013 22:06:43 UTC