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

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é
>
>

Received on Wednesday, 30 January 2013 18:47:58 UTC