Re: Why XForms 1.1 output/@mediatype exclude text/*?

We reached consensus some time ago on limiting *XForms* 1.1 to non-text 
media types precisely to avoid for now the problem of introducing into 
XForms the requirement to process host language constructs.

It is an easy thing to add to XHTML+XForms, but to the extent that XForms 
is still trying to be applicable to host languages other than XHTML, the 
feature becomes a little harder.

The hope was that we would ultimately come up with language that describes 
optional (in the RFC 2119 sense) functionality that can be introduced by a 
particular host language.  Such constructs do, however, still make it hard 
to port the core XForms from one host language to another, so it feels a 
bit like a hack feature that would be introduced for expediency rather 
than because it is the right thing to do.  I.e. it feels like something 
being pushed into XForms because it's easier than trying to push the right 
features into XHTML.

In any case, the consensus was that it was reasonable to encumber an 
XForms processor, regardless of host language, to process an image.  A 
non-visual language could ignore the image, but all different visual host 
langauges would show the image.  On the other hand, the handling of 
xforms:output by SVG or XFDL or XSL-FO should not be encumbered with the 
requirement to show the XHTML.

Cheers,
John M. Boyer, Ph.D.
Senior Product Architect/Research Scientist
Co-Chair, W3C XForms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com  http://www.ibm.com/software/

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer





Erik Bruchez <ebruchez@orbeon.com> 
Sent by: www-forms-request@w3.org
08/16/2006 04:03 PM

To
www-forms@w3.org
cc

Subject
Re: Why XForms 1.1 output/@mediatype exclude text/*?







I can only agree with that. Like FormsPlayer, OPS also implements 
mediatype="text/html" (on xforms:output and xforms:textarea), and it is 
a straightforward addition to the spec.

-Erik

Klotz, Leigh wrote:
> Why is the proposed XForms 1.1 output/@mediatype limited to nontext
> types?
> 
> http://www.w3.org/TR/xforms11/#render-nontext
> 
> Even before XForms 1.0, FormsPlayer had implemented and shown the value
> of output bound to text/html.
> 
> Since Atom support is a goal, this would fit right in, as RFC 4287
> defines two formats for carrying markup in text fields:
> An escaped text/html form and a complex-content application/xhtml+xml
> form. 
> 
> Here's how you could refer to an Atom title with xf:output/@mediatype,
> as described
> in http://atompub.org/rfc4287.html#text.constructs
>    <xf:output ref="atom:title[@type='html'] mediatype="text/html" />
> 
> I've recently written a mail reader in XHTML+XForms, and both output and
> textarea with @mediatype='text/html' would be great.
>   <xf:output ref="content" mediatype="text/html" />
>   ...
>   <xf:textarea ref="content"
> mediatype="text/html"><xf:label>Message</xf:label></xf:textarea>
> 
> Many existing browsers already support text/html editing in forms, and a
> number of JavaScript packages exist to make it easy to use.
> With XForms, just declaring the mediatype would make it easy to use!
> But user agents can't do this if XForms 1.1 explicitly limits mediatype
> to exclude text/* mediatypes.
> 
> Leigh.
> 
> 


-- 
Orbeon - XForms Everywhere:
http://www.orbeon.com/blog/