- From: T.V Raman <raman@google.com>
- Date: Thu, 17 Aug 2006 13:40:07 -0700
- To: Leigh.Klotz@xerox.com
- Cc: boyerj@ca.ibm.com, ebruchez@orbeon.com, www-forms@w3.org, www-forms-request@w3.org
I agree with leigh. In places where we dont the right answer, we should say what is allowed, not say "everything except what we've thought of yesterday is disallowed today". Klotz, Leigh writes: > 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/ > > > > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> > <HTML><HEAD> > <META http-equiv=Content-Type content="text/html; charset=us-ascii"> > <META content="MSHTML 6.00.2900.2963" name=GENERATOR></HEAD> > <BODY> > <DIV dir=ltr align=left><SPAN class=209454618-17082006><FONT face=Arial > color=#0000ff size=2>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.</FONT></SPAN></DIV> > <DIV dir=ltr align=left><SPAN class=209454618-17082006></SPAN> </DIV> > <DIV dir=ltr align=left><SPAN class=209454618-17082006> > <DIV dir=ltr align=left><SPAN class=209454618-17082006><FONT face=Arial > color=#0000ff size=2>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/*".</FONT></SPAN></DIV></SPAN></DIV> > <DIV dir=ltr align=left><SPAN class=209454618-17082006></SPAN><FONT > face=Arial><FONT color=#0000ff><FONT size=2>I<SPAN class=209454618-17082006>f > the goal is to require minimal support for certain images, then list the > types that are required, but </SPAN></FONT></FONT></FONT><FONT > face=Arial><FONT color=#0000ff><FONT size=2><SPAN class=209454618-17082006>I'm > not even sure that requiring support for image/* is > correct:</SPAN></FONT></FONT></FONT></DIV> > <DIV dir=ltr align=left><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN > class=209454618-17082006></SPAN><SPAN class=209454618-17082006><FONT>Should we > encumter XForms agents to present image/png with alpha > transparency?</FONT></SPAN></FONT></FONT></FONT></DIV> > <DIV dir=ltr align=left><SPAN class=209454618-17082006><FONT face=Arial > color=#0000ff size=2>Or image/tiff? (I have yet to find a program that can > display all image/tiff files by the way).</FONT></SPAN></DIV> > <DIV dir=ltr align=left><SPAN class=209454618-17082006><FONT face=Arial > color=#0000ff size=2></FONT></SPAN> </DIV> > <DIV dir=ltr align=left><SPAN class=209454618-17082006><FONT face=Arial > color=#0000ff size=2>Leigh.</FONT></SPAN></DIV> > <DIV dir=ltr align=left><SPAN class=209454618-17082006><FONT face=Arial > color=#0000ff size=2></FONT></SPAN> </DIV> > <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left> > <HR tabIndex=-1> > <FONT face=Tahoma size=2><B>From:</B> www-forms-request@w3.org > [mailto:www-forms-request@w3.org] <B>On Behalf Of </B>John Boyer<BR><B>Sent:</B> > Wednesday, August 16, 2006 5:26 PM<BR><B>To:</B> Erik Bruchez<BR><B>Cc:</B> > www-forms@w3.org; www-forms-request@w3.org<BR><B>Subject:</B> Re: Why XForms 1.1 > output/@mediatype exclude text/*?<BR></FONT><BR></DIV> > <DIV></DIV><BR><FONT face=sans-serif size=2>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.</FONT> <BR><BR><FONT face=sans-serif size=2>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.</FONT> <BR><BR><FONT face=sans-serif size=2>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.</FONT> <BR><BR><FONT > face=sans-serif size=2>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.</FONT> <BR><BR><FONT face=sans-serif > size=2>Cheers,</FONT> <BR><FONT face=sans-serif size=2>John M. Boyer, > Ph.D.<BR>Senior Product Architect/Research Scientist<BR>Co-Chair, W3C XForms > Working Group<BR>Workplace, Portal and Collaboration Software<BR>IBM Victoria > Software Lab<BR>E-Mail: boyerj@ca.ibm.com > http://www.ibm.com/software/<BR><BR>Blog: > http://www.ibm.com/developerworks/blogs/page/JohnBoyer<BR><BR></FONT><BR><BR><BR> > <TABLE width="100%"> > <TBODY> > <TR vAlign=top> > <TD width="40%"><FONT face=sans-serif size=1><B>Erik Bruchez > <ebruchez@orbeon.com></B> </FONT><BR><FONT face=sans-serif > size=1>Sent by: www-forms-request@w3.org</FONT> > <P><FONT face=sans-serif size=1>08/16/2006 04:03 PM</FONT> </P> > <TD width="59%"> > <TABLE width="100%"> > <TBODY> > <TR vAlign=top> > <TD> > <DIV align=right><FONT face=sans-serif size=1>To</FONT></DIV> > <TD><FONT face=sans-serif size=1>www-forms@w3.org</FONT> > <TR vAlign=top> > <TD> > <DIV align=right><FONT face=sans-serif size=1>cc</FONT></DIV> > <TD> > <TR vAlign=top> > <TD> > <DIV align=right><FONT face=sans-serif size=1>Subject</FONT></DIV> > <TD><FONT face=sans-serif size=1>Re: Why XForms 1.1 > output/@mediatype exclude text/*?</FONT></TR></TBODY></TABLE><BR> > <TABLE> > <TBODY> > <TR vAlign=top> > <TD> > <TD></TR></TBODY></TABLE><BR></TR></TBODY></TABLE><BR><BR><BR><TT><FONT > size=2><BR>I can only agree with that. Like FormsPlayer, OPS also implements > <BR>mediatype="text/html" (on xforms:output and xforms:textarea), and it is > <BR>a straightforward addition to the spec.<BR><BR>-Erik<BR><BR>Klotz, Leigh > wrote:<BR>> Why is the proposed XForms 1.1 output/@mediatype limited to > nontext<BR>> types?<BR>> <BR>> > http://www.w3.org/TR/xforms11/#render-nontext<BR>> <BR>> Even before > XForms 1.0, FormsPlayer had implemented and shown the value<BR>> of output > bound to text/html.<BR>> <BR>> Since Atom support is a goal, this would > fit right in, as RFC 4287<BR>> defines two formats for carrying markup in > text fields:<BR>> An escaped text/html form and a complex-content > application/xhtml+xml<BR>> form. <BR>> <BR>> Here's how you could > refer to an Atom title with xf:output/@mediatype,<BR>> as described<BR>> > in http://atompub.org/rfc4287.html#text.constructs<BR>> > <xf:output ref="atom:title[@type='html'] mediatype="text/html" > /><BR>> <BR>> I've recently written a mail reader in XHTML+XForms, and > both output and<BR>> textarea with @mediatype='text/html' would be > great.<BR>> <xf:output ref="content" mediatype="text/html" > /><BR>> ...<BR>> <xf:textarea ref="content"<BR>> > mediatype="text/html"><xf:label>Message</xf:label></xf:textarea><BR>> > <BR>> Many existing browsers already support text/html editing in forms, and > a<BR>> number of JavaScript packages exist to make it easy to use.<BR>> > With XForms, just declaring the mediatype would make it easy to use!<BR>> But > user agents can't do this if XForms 1.1 explicitly limits mediatype<BR>> to > exclude text/* mediatypes.<BR>> <BR>> Leigh.<BR>> <BR>> > <BR><BR><BR>-- <BR>Orbeon - XForms > Everywhere:<BR>http://www.orbeon.com/blog/<BR><BR></FONT></TT><BR></BODY></HTML> -- Best Regards, --raman Title: Research Scientist Email: raman@google.com WWW: http://emacspeak.sf.net/raman/ GTalk: raman@google.com, tv.raman.tv@gmail.com PGP: http://emacspeak.sf.net/raman/raman-almaden.asc Google: tv+raman
Received on Thursday, 17 August 2006 20:42:08 UTC