Re: XForms Reusability / Modularization (was RE: XForms WD 20020821 - 2.1 XForms and XHTML etc)

I'm a little confused by this threda:

What in the following is host language or rendering specific:

<model>...<!--declares field birthday of type date-->...</model>
user interface 
<input ref="birthdate">
<label> Day you were born</label>
...
</input>
or even more generically if you dont want to hard code the label:
<input ref="birthdate">
<label src="uri"/>
</input>

When I describe XForms today I get half the people saying 
"it's too generic --you'll never do a rich presentation with it"-
and the other half saying "it's too specific --you'll have to re-code
the UI for each host platform and language"--
given the 50-50 split --there may be a reasonable chance that we got
it completely right --
or have created something that is entirely useless i.e. everyone is
unhappy:-)

personally I think the XForms UI is sufficiently generic, and when
taken in conjunction with the type information present in the model
has enough information to produce a rich variety of end-user
presentation/interactions ranging from spoken dialogs to visual
interaction on display-challenged devices to full-featured desktop
clients.


>>>>> "joern" == joern turner <joern.turner@web.de> writes:

    joern> excellent analysis of an old XForms problem and completely
    joern> agreed!

    joern> i always considered XForms as a way to define
    joern> cross-platform forms (so i share Andrew's naive
    joern> perspective) and therefore tried to find solutions
    joern> delivering that (in principle) even if the official spec
    joern> doesn't necessarily reflect/considers this issue (yet).

    joern> IMHO cross-platform capability is a key requirement for a
    joern> generic form standard and i don't see why XForms shouldn't
    joern> be capable to deliver that one day.

    joern> maybe another perspective may add value to this discussion:
    joern> shouldn't form-processsing be considered separately from
    joern> form-rendering (excuse the implication to visual output
    joern> here) ?

    joern> for the purpose of form-processing no knowledge of the host
    joern> language is needed, cause it deals only with elements from
    joern> the xforms namespace (mainly doing manipulations on the
    joern> model).

    joern> but when rendering is done the host markup provides the
    joern> additional information needed for layout and this is where
    joern> the trouble starts...

    joern> i think the whole problem is introduced when XForms solely
    joern> builds on mixed-markup for solving the layout problem. i
    joern> say 'solely' cause mixed-markup may still be used without
    joern> making trouble for smaller projects. but for larger apps is
    joern> highly wishable (and a matter of cost) to separate layout
    joern> from the logical structure of the UI. so, other alternative
    joern> ways to deal with layout should be provided/possible...

    joern> Tomayko, Ryan wrote:
    >> Andrew raises some excellent points here and one worth digging
    >> further into.
    >> 
    >> 
    >> << How is a cross-platform XForms document to be written?
    >> 
    >> If the XForms code for the XHTML desktop platform is to be
    >> separated (as the
    >> 
    >> text quoted above suggests) into the xforms:model in the head
    >> element and the XForms form controls in the body element how is
    >> that to be adapted for, for example, use in an SVG and XForms
    >> Profile or for embedding in WML or other languages to be used
    >> on various mobile platforms.
    >> 
    >> I had naively assumed that XForms would be "write once, run
    >> everywhere" but if we are to carve up the XForms model and form
    >> controls according to (ill defined?) demands of host languages
    >> it seems that there will be a lot of rewriting and tweaking of
    >> XForms code to be done.
    >> 
    >> 
    >> Nail on the head. With the current facilities, it is absolutely
    >> impossible to write an XForms document which would be used in
    >> multiple host languages without modification. The reason's for
    >> this are as follows:
    >> 
    >> 1. In order to create a reusable XForms document, the document
    >> could assume no knowledge of the host language
    >> (profile). i.e. The XForms document could not contain elements
    >> or attributes from the host languages namespace.
    >> 
    joern> i agree with your first sentence here, but disagree with
    joern> the second: there's no need for a form-processor to deal
    joern> with the host-language at all (see above). that's why
    joern> namespaces are so cool - why not ignore what you're not
    joern> interested in ?


    >> 2. "XForms always requires such a host language." (Section 3)
    >> 
    >> 
    >> Alright, so it seems that there just isn't going to be entire
    >> XForms Documents which are capable of being
    >> "cross-profilable". So, let's look at this in pieces. What are
    >> the reusable parts and which are not? Let's assume we need to
    >> write both SVG and an HTML versions of the same XForm. What
    >> could we write once and what would we need to write in each
    >> profile.

    joern> why not use XHTML (or any other XML markup language) to
    joern> hold your forms - nobody urges you to interpret any of the
    joern> html elements for the purpose of processing. if it comes to
    joern> rendering you could e.g. use an additional 'user-agent'
    joern> parameter and select an appropriate transformation to
    joern> convert xforms ui elements into the ones used by the target
    joern> language (e.g. xforms:input -> html:input, ->
    joern> java.awt.textfield - see below)


    >>  1. Instance Documents
    >> 
    >> These are definitely reusable across XForms Documents in
    >> different host languages.
    >> 
    >> 2. Models (and all that's in them)
    >> 
    >> Hmmmm.. There's nothing in XForms that allows "importing" a
    >> model from a separate file but maybe there should be. There is
    >> nothing inside a model element that should require a specific
    >> host language. This makes models reusable in theory, there just
    >> isn't any way (built into XForms) of importing them. Maybe a
    >> src attribute on the xforms:model element would do the trick.
    >> 
    >> XInclude could be used to import models. If you knew whatever
    >> was processing the doc was capable of handling XInclude
    >> elements, models could be maintained in separate files and
    >> included into the host language.
    >> 
    >> 3. User Interface Controls
    >> 
    >> No way. I see very little hope for being able to use the same
    >> UI controls across different languages. To be more specific,
    >> you will not be able to modify an xforms:select1 element in a
    >> single place and have the changes propagate to each host
    >> language. XInclude is not even helpful here. Even if XForms
    >> provided some method for reusing UI controls, it wouldn't be
    >> much use as you will undoubtedly want to tweak at least one UI
    >> control in the document for each host languages.
    >> 
    >> This is why it's important that so much information be stored
    >> at the model level (relevance, readonly, required, etc..). The
    >> only things that should be specified on UI controls is the node
    >> it references (ref or bind) and any host language specific user
    >> interface stuff (CSS).
    >> 
    >> Any other comments on this topic are greatly appreciated. I
    >> like the idea of looking outside of XForms itself to provide
    >> modularity (i.e. XInclude). Can anyone think of how XSLT might
    >> be used to combine a pure XForms document with a host language
    >> document and get a "Host Language + XForms" result? I have some
    >> vague ideas but none worth leaving my head.

    joern> i'm currently working along the following lines.

    joern> provide two ways to generate the UI: [1] mixed-markup as
    joern> proposed by spec - this ties the form to the host-language
    joern> as you've stated, but is ok, if you only want to serve one
    joern> client or for prototyping

    joern> [2] consider the XForms UI of a given form a
    joern> meta-description of a UI which is to be transformed into
    joern> target client language. this requires to write a mapping
    joern> for each UI element to the appropriate target language
    joern> element (html:input, java.awt.textfield, whatever) e.g. as
    joern> a XSLT transformation AND provide a layout transformation
    joern> to be applied on the result of the first transform. this
    joern> allow to separate layout from the logical description of
    joern> the UI in XForms.

    joern> this also solves applying company-styles on many forms even
    joern> when there's no CSS.

    joern> Joern

    >>  - Ryan
    >> 
    >> 
    >> -----Original Message----- From: AndrewWatt2001@aol.com
    >> [mailto:AndrewWatt2001@aol.com] Sent: Thursday, August 29, 2002
    >> 7:36 AM To: www-forms@w3.org; www-forms-editor@w3.org;
    >> xforms@yahoogroups.com Subject: XForms WD 20020821 - 2.1 XForms
    >> and XHTML etc
    >> 
    >> 
    >> 
    >> In Chapter 2.1, it is stated (without further explanation):
    >> 
    >> "This can be represented in the XForms model element, which in
    >> XHTML would be contained within the head element".
    >> 
    >> It seems to me that this is not a statement that can be made
    >> without qualification. It is not, as far as I am aware, true
    >> for XHTML 1.0.  Therefore I suggest that consideration be given
    >> to adding a version number to the statement.
    >> 
    >> In addition, as far as I can see, there is nothing in the
    >> initial XHTML 2.0 WD which constrains the xforms:model element
    >> to being present nested in the XHTML head element. Is there
    >> anything to prevent the xforms:model element being present in
    >> the body element but simply not be rendered?
    >> 
    >> Did I miss something? Or is the XForms WD making an assumption
    >> that may not necessarily be true? If it is merely an assumption
    >> then some redrafting might be in order.
    >> 
    >> It also raised, for me at least, an issue which I hadn't
    >> considered in detail before. This is partly because I had
    >> focussed on using XForms on a single platform as I tried to get
    >> to grips with the detail of XForms.
    >> 
    >> How is a cross-platform XForms document to be written?
    >> 
    >> If the XForms code for the XHTML desktop platform is to be
    >> separated (as the
    >> 
    >> text quoted above suggests) into the xforms:model in the head
    >> element and the XForms form controls in the body element how is
    >> that to be adapted for, for example, use in an SVG and XForms
    >> Profile or for embedding in WML or other languages to be used
    >> on various mobile platforms.
    >> 
    >> I had naively assumed that XForms would be "write once, run
    >> everywhere" but if we are to carve up the XForms model and form
    >> controls according to (ill defined?) demands of host languages
    >> it seems that there will be a lot of rewriting and tweaking of
    >> XForms code to be done.
    >> 
    >> Is there a mechanism which I am overlooking which will allow
    >> modular XForms code to be re-used as is across platforms?
    >> 
    >> Am I missing something obvious here, which is always possible?
    >> Or is creation of cross-platform XForms code going to be less
    >> transparent than I had (naively?) assumed?
    >> 
    >> Andrew Watt
    >> 
    >> 

-- 
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://www.cs.cornell.edu/home/raman
AIM:      TVRaman
PGP:          http://emacspeak.sf.net/raman.asc
Snail:        IBM Almaden Research Center,
              650 Harry Road
              San Jose 95120

Received on Friday, 30 August 2002 17:55:29 UTC