xf:output, @mediatype and @value

[Philipp Wagner-4]

Hi,

recently Mozilla XForms got a bug report [1] that the following is not
working:

<xf:output mediatype="image/png" value="'xml.png'"/>

Expected behavior was displaying the image. The real use case for this
remains unclear (you could just use a html:img in that case or whatever
the host language provides you to display images).

While the fix is straightforward, a question remains:
Are we always supposed to treat @value as anyURI if @mediatype is set to
"image/*"? Orbeon seems to do this for at least this case as well [2].
Are there other cases where we should/could make such an assumption?

A clarification would be greatly appreciated.

Philipp


[1] https://bugzilla.mozilla.org/show_bug.cgi?id=507621
[2]
http://www.orbeon.com/ops/doc/reference-xforms-guide#xforms-image-mediatype

[John Boyer]

HI Philipp,

It is no bug in the FF plugin.  Also, the spec does not need clarification.

The configuration of using mediatype with the value attribute is explicitly not supported by the specification.

The mediatype attribute helps an output control to determine how to render data obtained from the single node binding only.  This is necessary because the XForms data model provides the additional expressivity needed to pull off the feature correctly (via the type model item property in this case).  The value attribute is only capable of providing a string of text.  It is not possible currently to indicate that the string is a base 64 encoding of the image or a URL to be dereferenced, or what have you.  

The correct way to activate the feature would be like this:

<xf:model ... namespace declarations ...>
   <xf:instance>
      <myData xmlns="">
         ...
         <image>myPicture.png</image>
      </myData>
   </xf:instance>

   <xf:bind nodeset="myPicture" type="xsd:anyURI" />
   ...
</xf:model>
...
<xf:output ref="myPicture" mediatype="image/*"> ... </xf:output>

So, it's not that the feature isn't there.  It's just that the feature is activated via different markup.  In this situation, a particular implementation has added/supported a custom alternative markup pattern.  I hesitate to call it an "extension" because usually that term is reserved for things which are not otherwise achievable by the specification.  While it is usually the case that one reports a bug when something doesn't appear, in this case the implementation should receive a bug report because the image does appear when the value attribute is used to provide an image filename.  This is necessary in order to avoid creating exactly this kind of confusion across implementations, and it also helps to ensure that the correct markup pattern is used to activate the feature in a way that is interoperable across implementations.

Finally, hopefully with the connection to data, it might be clearer why this mechanism is preferable to just using an img tag.  One can change the data node, e.g. with a setvalue action or with a web service result, and the image rendered by the output will change as a result.

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

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

From:	Philipp Wagner <news@...>
To:	www-forms@...
Date:	08/11/2009 02:11 PM
Subject:	xf:output, @mediatype and @value

---

Hi,

recently Mozilla XForms got a bug report [1] that the following is not
working:

<xf:output mediatype="image/png" value="'xml.png'"/>

Expected behavior was displaying the image. The real use case for this
remains unclear (you could just use a html:img in that case or whatever
the host language provides you to display images).

While the fix is straightforward, a question remains:
Are we always supposed to treat @value as anyURI if @mediatype is set to
"image/*"? Orbeon seems to do this for at least this case as well [2].
Are there other cases where we should/could make such an assumption?

A clarification would be greatly appreciated.

Philipp


[1] https://bugzilla.mozilla.org/show_bug.cgi?id=507621
[2]
http://www.orbeon.com/ops/doc/reference-xforms-guide#xforms-image-mediatype

[Philipp Wagner-4]

Hi John,

John Boyer wrote:

> The configuration of using mediatype with the value attribute is
> explicitly not supported by the specification.
>
> [...]
>
> The correct way to activate the feature would be like this:
>
> <xf:model ... namespace declarations ...>
>    <xf:instance>
>       <myData xmlns="">
>          ...
>          <image>myPicture.png</image>
>       </myData>
>    </xf:instance>
>
>    <xf:bind nodeset="myPicture" type="xsd:anyURI" />
>    ...
> </xf:model>
> ...
> <xf:output ref="myPicture" mediatype="image/*"> ... </xf:output>
>
> So, it's not that the feature isn't there.  It's just that the feature
> is activated via different markup.  

This way of displaying an image is clear and also supported by Mozilla
XForms.

> In this situation, a particular
> implementation has added/supported a custom alternative markup pattern.
>  I hesitate to call it an "extension" because usually that term is
> reserved for things which are not otherwise achievable by the
> specification.  While it is usually the case that one reports a bug when
> something doesn't appear, in this case the implementation should receive
> a bug report because the image does appear when the value attribute is
> used to provide an image filename.  This is necessary in order to avoid
> creating exactly this kind of confusion across implementations, and it
> also helps to ensure that the correct markup pattern is used to activate
> the feature in a way that is interoperable across implementations.

OK. So you suggest removing support for that markup variation and filing
a bug report with Orbeon? What should we output instead? The string (and
ignoring @mediatype) or nothing (as the string cannot be displayed as
image)?

@Erik Bruchez: why did you add this variation in the first place? Do you
see a use case for this?

Philipp

> From: Philipp Wagner <news@...>
> To: www-forms@...
> Date: 08/11/2009 02:11 PM
> Subject: xf:output, @mediatype and @value
>
>
> ------------------------------------------------------------------------
>
>
>
> Hi,
>
> recently Mozilla XForms got a bug report [1] that the following is not
> working:
>
> <xf:output mediatype="image/png" value="'xml.png'"/>
>
> Expected behavior was displaying the image. The real use case for this
> remains unclear (you could just use a html:img in that case or whatever
> the host language provides you to display images).
>
> While the fix is straightforward, a question remains:
> Are we always supposed to treat @value as anyURI if @mediatype is set to
> "image/*"? Orbeon seems to do this for at least this case as well [2].
> Are there other cases where we should/could make such an assumption?
>
> A clarification would be greatly appreciated.
>
> Philipp
>
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=507621
> [2]
> http://www.orbeon.com/ops/doc/reference-xforms-guide#xforms-image-mediatype

[John Boyer]

Hi Philipp,

The most natural reading is that the mediatype attribute is simply ignored when an output has a value attribute and not a single node binding.  Output with a single node binding can be further qualified by the mediatype attribute.  Output with a value attribute only shows the string result of the value attribute's expression.

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

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

From:	Philipp Wagner <news@...>
To:	www-forms@...
Cc:	ebruchez@...
Date:	08/12/2009 09:52 AM
Subject:	Re: xf:output, @mediatype and @value

---

Hi John,

John Boyer wrote:
> The configuration of using mediatype with the value attribute is
> explicitly not supported by the specification.
>
> [...]
>
> The correct way to activate the feature would be like this:
>
> <xf:model ... namespace declarations ...>
>    <xf:instance>
>       <myData xmlns="">
>          ...
>          <image>myPicture.png</image>
>       </myData>
>    </xf:instance>
>
>    <xf:bind nodeset="myPicture" type="xsd:anyURI" />
>    ...
> </xf:model>
> ...
> <xf:output ref="myPicture" mediatype="image/*"> ... </xf:output>
>
> So, it's not that the feature isn't there.  It's just that the feature
> is activated via different markup.  

This way of displaying an image is clear and also supported by Mozilla
XForms.

> In this situation, a particular
> implementation has added/supported a custom alternative markup pattern.
>  I hesitate to call it an "extension" because usually that term is
> reserved for things which are not otherwise achievable by the
> specification.  While it is usually the case that one reports a bug when
> something doesn't appear, in this case the implementation should receive
> a bug report because the image does appear when the value attribute is
> used to provide an image filename.  This is necessary in order to avoid
> creating exactly this kind of confusion across implementations, and it
> also helps to ensure that the correct markup pattern is used to activate
> the feature in a way that is interoperable across implementations.

OK. So you suggest removing support for that markup variation and filing
a bug report with Orbeon? What should we output instead? The string (and
ignoring @mediatype) or nothing (as the string cannot be displayed as
image)?

@Erik Bruchez: why did you add this variation in the first place? Do you
see a use case for this?

Philipp



> From:                  Philipp Wagner <news@...>
> To:                  www-forms@...
> Date:                  08/11/2009 02:11 PM
> Subject:                  xf:output, @mediatype and @value
>
>
> ------------------------------------------------------------------------
>
>
>
> Hi,
>
> recently Mozilla XForms got a bug report [1] that the following is not
> working:
>
> <xf:output mediatype="image/png" value="'xml.png'"/>
>
> Expected behavior was displaying the image. The real use case for this
> remains unclear (you could just use a html:img in that case or whatever
> the host language provides you to display images).
>
> While the fix is straightforward, a question remains:
> Are we always supposed to treat @value as anyURI if @mediatype is set to
> "image/*"? Orbeon seems to do this for at least this case as well [2].
> Are there other cases where we should/could make such an assumption?
>
> A clarification would be greatly appreciated.
>
> Philipp
>
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=507621
> [2]
> http://www.orbeon.com/ops/doc/reference-xforms-guide#xforms-image-mediatype

[Erik Bruchez]

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

[John Boyer]

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

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@...>
To:	www-forms@...
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