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

excellent analysis of an old XForms problem and completely agreed!

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

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

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

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

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

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

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.
> 
i agree with your first sentence here, but disagree with the second: 
there's no need for a form-processor to deal with the host-language at 
all (see above). that's why namespaces are so cool - why not ignore what 
you're not 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.

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

i'm currently working along the following lines.

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

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

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

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
> 
>

Received on Thursday, 29 August 2002 18:21:58 UTC