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

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.

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.

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.

- 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 10:35:41 UTC