- From: Robert Simmons <derisor@arcor.de>
- Date: Fri, 29 Aug 2003 18:29:31 +0200
- To: www-forms@w3.org
I wholeheartedly DISAGREE. XForms in my mind is a way to declaritively specify forms that the rendering authority can render as they see fit. In my mind what you are talkign about is XSLT and not XForms. I certainly would want to keep the minimum of "appearance" information out of the form. What if someone contacts your form via a Cellular Phone. Then just exactly how are you going to pop open microsoft word on a 4 cm x 4cm screen. If you want to customize appearance you are seriously barking up the wrong tree in my opinion and should be looking at XSLT. -- Robert "Mark Birbeck" <Mark.Birbeck@x-port.net> wrote in message news:E3ED00A7C285EE408679DE2A26D1C7810148F6EA@S007.x-port.net... > > Robert, > > You wrote: > > Why would you want to? XForms is a model for data entry and is not > > related to presentation logic or data processing at all. Mixing them > > would be ... bad. In fact the separation of presentation and data entry > > model is at the core of the driving force for XForms. > > I think the original question was perfectly legitimate. Whilst it is true > that XForms has as a goal the separation of presentation and data, this is > only at the level of the mark-up. At the core of XForms is the desire to be > *very* specific in terms of actual run-time presentation. So if a user is > French, they should see a French calendar when asked for a date, and if they > are Japanese they should see a Japanese one. If they are blind they should > have a voice speak to them, and be able to make their selection by speaking. > Of course at no point in our mark-up should we need to mention French or > Japanese calendars, or voice systems - we simply ask for the ability to > input a date - and that is the core of the separation to which you refer. > > So, as long as data gets transferred to the instance as (for example): > > <my:article><b>hello</b> <i>mum</i></my:article> > > then it doesn't matter how the user entered it. If it is easier for a user > of a visual system to highlight some text and then press 'B' on a toolbar to > make it 'bold', then let them do that. And if it should be done with a > right-mouse menu, then do that too. As I said before, let's be very specific > in our run-time rendering, and agnostic in our mark-up. > > How we actually indicate this in a general way will probably be established > as people start to use XForms more and more. One possibility might be to > agree some values for the @appearance attribute: > > <xforms:textarea ref="my:article" appearance="widgets:rich-text"> > <xforms:label>Please type your article</xforms:label> > </xforms:textarea> > > On one platform "widgets:rich-text" might refer to a Microsoft Word control > in the form, and on another it might be Open Office. Note one of the nice > features of XForms here, in that since @appearance is only a hint, if the > device executing the form hasn't got a rich-text editor on it, then we just > fall back to an ordinary xf:textarea control. > > Another possibility might be for XForms processors to be configured to > invoke a rich-text editor in the same way that a date control is > instantiated, and all you would need is to define some schema type in your > instance data and bind it to the correct handler. > > Now that XForms 1.0 is stable we have a strong foundation onto which to > layer features like this - there are some exciting possibilities ahead! > > Regards, > > Mark > > > Mark Birbeck > Co-author Professional XML and > Professional XML Meta Data, > both by Wrox Press > > Download our XForms processor for IE6 > from http://www.formsPlayer.com/ > > Managing Director > x-port.net Ltd. > 4 Pear Tree Court > London > EC1R 0DS > > E: Mark.Birbeck@x-port.net > W: www.x-port.net > T: +44 (20) 7689 9232 > >
Received on Friday, 29 August 2003 12:29:06 UTC