- From: Klotz, Leigh <Leigh.Klotz@xerox.com>
- Date: Thu, 17 Aug 2006 11:51:02 -0700
- To: "John Boyer" <boyerj@ca.ibm.com>, "Erik Bruchez" <ebruchez@orbeon.com>
- Cc: <www-forms@w3.org>, <www-forms-request@w3.org>
- Message-ID: <E254B0A7E0268949ABFE5EA97B7D0CF4021EB617@usa7061ms01.na.xerox.net>
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 UTC