- From: Erik Bruchez <ebruchez@orbeon.com>
- Date: Thu, 13 Aug 2009 10:01:59 +0800
- 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. -Erik
Received on Thursday, 13 August 2009 02:02:59 UTC