Re: xf:output, @mediatype and @value

I had first thought that perhaps it was a reasonable extension, but then I 
realized that it amounted to having the mediatype attribute controlling 
how we interpret the data type of the value attribute result.  I think 
this is how we ended up not doing it in the first place.  The point is 
that if mediatype an always present property of an output, then the 
default when the attribute is not specified would be text/plain.  Then, 
we'd be saying that if the mediatype is text/plain, then the result of 
value is a string of text.  Good so far.  If mediatype is image/*, then 
the result of value is interpreted as xsd:anyURI.  OK, now what if the 
mediatype is text/html?

So, this can go on the discussion list for 1.2, but I suspect we will be 
unable to avoid an articulation of the data type distinct from the 
mediatype.  Further, this can also be done in a manner that is inline with 
an "on the glass" (attribute decoration) approach by simply using a 
separate attribute, e.g.

<output mediatype="image/*" datatype="anyURI" value=" concat(some 
expression, '.png') "/>

The extra attribute would make the "extension" a lot more palatable, I 
believe.

The issue of simultaneous use of single node binding and value attribute 
on output has also come up, and the group decided not to do that for some 
reason.  I think it was that it was late in the 1.1 schedule, there was an 
easy way to do the same thing by just putting the output in a group, and 
there was a bit of a feeling that it might be too much special case 
behavior for output.  In my view, the special case is already there in the 
fact that output has a value.  Still, we would have to think about the 
ramifications a bit more, e.g. receiving xforms-value-changed when the 
value does not change, impact of evaluation ref on the eval context of the 
value, etc.

Will put it on the group agenda.

Cheers,
John M. Boyer, Ph.D.
STSM, Interactive Documents and Web 2.0 Applications
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed: 
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw





From:
Erik Bruchez <ebruchez@orbeon.com>
To:
www-forms@w3.org
Date:
08/12/2009 07:07 PM
Subject:
Re: xf:output, @mediatype and @value



> @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.

-Erik