W3C home > Mailing lists > Public > public-forms@w3.org > February 2013

Re: XForms 2.0 Draft review: The mediatype Element (for upload)

From: Ulrich Nicolas Lissé <unlisse@gmail.com>
Date: Tue, 5 Feb 2013 15:43:25 +0100
Message-ID: <CAJmsKWC8Wg+_v7DbN1pf-Bd2g-SvvX5nSORod+2Hvzsc3hwLvA@mail.gmail.com>
To: Erik Bruchez <erik@bruchez.org>
Cc: Forms WG <public-forms@w3.org>

agreed, no AVT for xf:mediatype/@ref. I embarrassingly ignored the
fact that it is a binding expression.

I completely agree with your findings. However, I think we should
deprecate xf:filename, too. To sum up, we should:

- remove the current deprecation language in [1]
- introduce xf:upload/@accept
- deprecate xf:upload/@mediatype in favor of xf:upload/@accept
- introduce xf:upload/@mediatyperef
- deprecate xf:mediatype in favor of xf:upload/@mediatyperef
- introduce xf:upload/@filenameref
- deprecate xf:filename in favor of xf:upload/@filenameref


[1] http://www.w3.org/MarkUp/Forms/wiki/XForms_2.0#The_mediatype_Element_.28for_upload.29

On Wed, Jan 30, 2013 at 7:47 PM, Erik Bruchez <erik@bruchez.org> wrote:
> Uli,
> Agreed on the unfortunate double meaning of "mediatype" on xf:upload.
> In general, the rule should be that a child element has the same
> meaning as an attribute with the same name, and for xf:upload, this
> has not been the case since XForms 1.0.
> I disagree on one point however: we shouldn't use an AVT if/when we
> introduce a new attribute to correspond to the nested xf:mediatype
> element. That's because an AVT always ends up being converted to a
> string, which is the resulting value of the attribute.
> You can conceive of an AVT producing the string of an XPath expression, but:
> 1. That leads to hard to read code (code generating code).
> 2. XForms 2.0 doesn't do this anywhere else.
> 3. It's not needed as you can instead specify that the attribute takes
> an XPath expression in the first place.
> Currently, XForms 2.0 doesn't allow AVTs for any attribute which is
> already an XPath expression. The rationale is that an AVT is designed
> to make something which used to be (or usually is) a static value,
> into a dynamic one. But if you always need an XPath expression, as in
> the case of a binding (such as xf:mediatype/@ref), then you should
> just specify that the attribute is an XPath expression in the first
> place.
> So instead, if we want an attribute as a lighter-weight notation, we
> should use an attribute ending in "ref" or "-ref". We have precedents
> for this, such as targetref, caseref, and indexref.
> So:
> <xf:upload>
>   <xf:mediatype ref="/foo/bar"/>
> </xf:upload>
> becomes:
> <xf:upload mediatyperef="/foo/bar"/>
> This doesn't invalidate your suggestion that we should use another
> attribute name for the mediatypes accepted. So you could have:
> <xf:upload mediatyperef="/foo/bar" accept="image/*"/>
> @accept would here be an AVT, but mediatyperef wouldn't be one.
> In short:
> - we must not say that we deprecate the nested xf:mediatype element
> for the @mediatype attribute, as the two have different meanings
> - we could deprecate @mediatype and introduce @accept instead
> - we could introduce a new @mediatyperef attribute corresponding to
> the nested xf:mediatype element
> - if we do that, the we could deprecate the nested xf:mediatype element
> -Erik
> On Wed, Jan 30, 2013 at 2:09 AM, Ulrich Nicolas Lissé <unlisse@gmail.com> wrote:
>> Dear Group,
>> http://www.w3.org/MarkUp/Forms/wiki/XForms_2.0#The_mediatype_Element_.28for_upload.29
>> states that this element is "deprecated in favor of using an AVT in
>> the mediatype attribute". This cannot work, since the mediatype
>> element for upload is no surrogate for the mediatype attribute.
>> The issue here is that we have to deal with two different mediatype
>> aspects of upload: The mediatype attribute is used to constrain upload
>> sources presented to the user. In contrast, the mediatype child
>> element is used to store the actual mediatype of the uploaded
>> resource.
>> Unfortunately, both the attribute and the element have been given the
>> same name. This must change in order to take advantage of AVTs for the
>> mediatype element. I'd like to suggest to introduce a new "accept"
>> attribute, which takes on the role of the old mediatype attribute. The
>> mediatype attribute can be used as an AVT-enabled child element
>> surrogate then. However, this would create a sneaky backwards
>> incompatibility. So we should leave the mediatype attribute as is and
>> introduce a new AVT-enabled attribute for the deprecated mediatype
>> element, if we come up with an appropriate name.
>> Regards,
>> Uli.
>> --
>> Ulrich Nicolas Lissé

Ulrich Nicolas Lissé
Received on Tuesday, 5 February 2013 14:44:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:48:54 UTC