W3C home > Mailing lists > Public > public-xformsusers@w3.org > April 2012

Re: Upload limitations

From: Joern Turner <joern.turner@betterform.de>
Date: Tue, 03 Apr 2012 21:46:25 +0200
Message-ID: <4F7B5391.1040803@betterform.de>
To: Alain Couthures <alain.couthures@agencexml.com>
CC: public-xformsusers@w3.org
Hi Alan,

Am 03.04.12 21:14, schrieb Alain Couthures:
> Hello,
>
> While implementing upload control in XSLTForms
> (http://www.agencexml.com/xsltforms/uploads.xml), I was wondering in
> what real use cases it can be used.
>
> With xsi:anyURI type, the server only gets a filename (usually prefixed
> by "fakedpath") for security reasons. So, only the short name (not the
> full path) is meaningful.
True - however in our scenario (server-side) it's no problem to 
de-reference this link against the root-context of the application. So 
it's just a standard file upload. For bigger files where the instance 
data store some meta-data this is the right solution.
>
> With xsi:hexBinary and xsi:base64Binary, the full content of the chosen
> file is copied and expanded (2 times or 1.67 times respectively) within
> an instance. Uploading big files will require time (and memory) and a
> progress bar with a cancel option would be useful and, then, submission
> will also take time...
I think these two options are surely more appropriate when you want to 
use to store smaller pieces of data (esp. binary data) that you'd like 
to include directly within your instance data. We had a practical 
example when building a configuration frontend for a security appliance 
that use certificates. It was a convenient fit here to store the certs 
base64 encoded directly within the configuration file.

Btw, our upload has a progress indicator though we do not have a cancel 
option yet - and due to the browser security model it's very hard to 
implement an effective cancel option.

Joern

>
> So, what are the effective or expected use cases for the upload control?
>
> Thank you for your answers!
>
> -Alain
>
>
>
Received on Tuesday, 3 April 2012 19:46:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:48:23 UTC