W3C home > Mailing lists > Public > www-forms@w3.org > August 2009

Re: xf:output, @mediatype and @value

From: Erik Bruchez <ebruchez@orbeon.com>
Date: Thu, 13 Aug 2009 10:01:59 +0800
Message-ID: <e81b48eb0908121901y39a98550wd3830252efb12bac@mail.gmail.com>
To: www-forms@w3.org
> @Erik Bruchez: why did you add this variation in the first place? Do you
> see a use case for this?

I am not sure we had realized that this was contrary to the spec, but
after re-reading the text I agree with John that the spec is in fact
quite clear on this point!

We have a case where we want to display a user-defined logo. The URL
of the logo can come from one of 3 different sources (different
instances). We simply determine that source with an expression in the
@value attribute on xf:output. The XForms 1.1-compliant way would
require creating a new instance to store the effective URL of the
image, and either use @xsi:type or xforms:bind/@type to specify the
data type.

In our implementation, if no instance-data type is specified, then we
just default to xs:anyURI, as it is less likely that one would compute
an xs:base64Binary or xs:hexBinary.

The bottom line is that allowing @mediatype interpretation with @value
can make the syntax lighter in some cases. As a side note, while
against the current spec, conceptually this is in line with
discussions we have had over the past 1-2 years in the working group
about allowing more markup "on the glass" (i.e. without requiring
explicit model markup).

Note that I realize that there is another part where our
implementation differs with the spec: we allow both single-node
binding and @value at the same time. In such a case, the single-node
binding provide MIP information to the xforms:output control
(including relevance and datatype), and @value (evaluated against the
context set by the single-node binding) is used to evaluate the actual
control value.

I am not sure why neither of these constructs is allowed by the spec.
They seem to me like quite natural extensions.

Received on Thursday, 13 August 2009 02:02:59 UTC

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