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

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

From: Klotz, Leigh <Leigh.Klotz@xerox.com>
Date: Thu, 17 Aug 2006 11:51:02 -0700
Message-ID: <E254B0A7E0268949ABFE5EA97B7D0CF4021EB617@usa7061ms01.na.xerox.net>
To: "John Boyer" <boyerj@ca.ibm.com>, "Erik Bruchez" <ebruchez@orbeon.com>
Cc: <www-forms@w3.org>, <www-forms-request@w3.org>
I'm not sure I believe limiting xf:output to non-text is the right way
to approach the requirement for minimal support for images.
 
I would recommend that we remove the "processors must not support
text/*" and replace it with something on the lines of "processors should
support image/*".
If the goal is to require minimal support for certain images, then list
the types that are required,  but I'm not even sure that requiring
support for image/* is correct:
Should we encumter XForms agents to present image/png with alpha
transparency?
Or image/tiff?  (I have yet to find a program that can display all
image/tiff files by the way).
 
Leigh.
 
________________________________

From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On
Behalf Of John Boyer
Sent: Wednesday, August 16, 2006 5:26 PM
To: Erik Bruchez
Cc: www-forms@w3.org; www-forms-request@w3.org
Subject: 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/
Received on Thursday, 17 August 2006 18:54:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:22:06 GMT