W3C home > Mailing lists > Public > www-forms@w3.org > November 2003

Xforms appearances without stylesheets

From: T. V. Raman <tvraman@us.ibm.com>
Date: Wed, 19 Nov 2003 13:24:45 -0800
Message-ID: <16315.57245.338956.442141@bubbles.almaden.ibm.com>
To: rbrett@fieldpine.co.nz
Cc: www-forms@w3.org


If you use appearance for this purpose you can say
appearance="my:look-and-feel".

I would counsel against appearance="radio" etc --even if you're
not interested in browser based solutions --since that mixes
purpose with presentation.

With respect to style-sheets --the intent behind describing
things in terms of CSS was that in environments where you didn't
have style-sheet functionality i.e. the styling was fixed--
you would implement it "as if you had a fixed style-sheet".
This also gives you the ability to describe "how" your
implementation  displays a form in terms of a CSS stylesheet
that you can hand to someone else who wishes to create the same
look-and-fell in a browser environment.

>>>>> "Richard" == Richard Brett <rbrett@fieldpine.co.nz> writes:
    Richard> Hello
    Richard> 
    Richard>   We are starting to use XForms for generating
    Richard> screens dynamically from XSD and other XML document
    Richard> types.  This is a being used in an application that
    Richard> receives SOAP requests and may need to present user
    Richard> input, but without knowing until runtime how the
    Richard> form will appear exactly (ie, no static form
    Richard> definitions).  To do this, we dynamically convert
    Richard> xsd/xml to xforms and have implemented some code to
    Richard> then convert xforms into user presentation screens.
    Richard> Note, we have not implemented all of xforms, so are
    Richard> not claiming to be a conforming application.
    Richard> 
    Richard> Our "output" devices are not browser based, and we
    Richard> do not have stylesheets ability, which is driving
    Richard> some of the following questions.  I aren't totally
    Richard> keen to implement stylesheets, and are searching for
    Richard> ideas on how others using XForms in constrained
    Richard> environments may have solved some problems.
    Richard> 
    Richard> 
    Richard> Question: Actual item appearance. While the standard
    Richard> says we can use appearance=full | simple |
    Richard> QName-but-not-NCName I haven't found much on what
    Richard> the final tag is for?  Can we overload this to
    Richard> provide a series of extended input display styles
    Richard> eg, "radio", "tickbox", or does it have another
    Richard> purpose?  To clarify, the simple sex entry of M/F
    Richard> can be presented to the user in many different
    Richard> styles, and the list of full/simple is potentially
    Richard> not strongly defined enough for some of our customer
    Richard> requirements.
    Richard> 
    Richard> The options I can see are: a)
    Richard> appearance="our-style-name"
    Richard> 
    Richard> b) <extension> ?
    Richard> 
    Richard> c) Simply add a new attribute to element tags for
    Richard> our own purposes <select ....
    Richard> my-private-style-hint="popup-window">
    Richard> 
    Richard> d) implement style="stylesheet options", so that
    Richard> stylesheet elements can be embedded, are not require
    Richard> a CSS file to be called.
    Richard> 
    Richard> e) Am I just wrong to try and use Xforms to control
    Richard> the appearance also, and should be using it only to
    Richard> control the "purpose" (as per requirements spec),
    Richard> and implement a separate "presentation" layer around
    Richard> xforms?
    Richard> 
    Richard> 
    Richard>  While I know we can choose whatever we like as we
    Richard> currently draw the output from the forms ourselves,
    Richard> I know that these forms will end up in time being
    Richard> displayed on other web based devices too, so want to
    Richard> chose a method that fits general standard direction.
    Richard> 
    Richard> 
    Richard> Thanks for any guidance .Richard (Constantly
    Richard> concerned he just hasnt read some part of the
    Richard> documentation before asking this question....)

-- 
Best Regards,
--raman
------------------------------------------------------------
T. V. Raman:  PhD (Cornell University)
IBM Research: Human Language Technologies
Architect:    Conversational And Multimodal WWW Standards
Phone:        1 (408) 927 2608   T-Line 457-2608
Fax:        1 (408) 927 3012     Cell: 1 650 799 5724
Email:        tvraman@us.ibm.com
WWW:      http://almaden.ibm.com/u/tvraman
AIM:      TVRaman
GPG:          http://www.almaden.ibm.com/cs/people/tvraman/raman-almaden.asc
Snail:        IBM Almaden Research Center,
              650 Harry Road
              San Jose 95120
Received on Wednesday, 19 November 2003 16:26:09 GMT

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