W3C home > Mailing lists > Public > www-forms@w3.org > April 2005

RE: Directory picker control

From: Klotz, Leigh <Leigh.Klotz@xerox.com>
Date: Mon, 18 Apr 2005 10:58:25 -0700
Message-ID: <E254B0A7E0268949ABFE5EA97B7D0CF44C5D26@usa7061ms01.na.xerox.net>
To: "Mark Birbeck" <mark.birbeck@x-port.net>
Cc: "Micah Dubinko" <micah@dubinko.info>, <www-forms@w3.org>

Thanks for pointing it out.  I was exploring upload without binding on
the primary binding site for 1.1, not for Xforms 1.0, where it is
clearly mandatory.

It's not clear to me what the right thing for an implementation to do is
when upload is bound to xsd:anyURI and the serialization mechanism is
not multipart/related, which is what I think your idea is.  It does
possible that sending a URI only would be reasonable.  

But what happens if you have two uploads bound to different sites in the
same instance, and one needs to upload a file, and the other doesn't?
If you specify multipart/related submission, then both will upload


-----Original Message-----
From: Mark Birbeck [mailto:mark.birbeck@x-port.net] 
Sent: Saturday, April 16, 2005 5:03 AM
To: Klotz, Leigh
Cc: 'Micah Dubinko'; www-forms@w3.org
Subject: FW: Directory picker control

Hi Leigh,

> Micah,
> Are you imagining this?
> <upload>
>  <label>foo</label>
>  <filename ref="fn" />
> </upload>
> I.e., upload with no single-node binding attributes? 

Unfortunately you cannot leave off the single node binding. 
However, the spec already allows for us to do what Micah wants, as
follows (I think it was actually you who designed this feature!):

  <xf:bind nodeset="my-file" type="xsd:anyURI" />

  <xf:upload ref="my-file">
    <xf:label>Choose file</xf:label>

I like this approach, since -- in keeping with the 'principles' of
XForms -- we obtain different behaviour at the UI level by changing the
data type at the model level.



Mark Birbeck
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
w: http://www.formsPlayer.com/
b: http://internet-apps.blogspot.com/

Download our XForms processor from
Received on Monday, 18 April 2005 17:59:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:15 UTC