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

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

Yes, definitely. I should have been more clear on my statement. The
implementation I'm working on supports HTML+XForms and could support
WML+XForms very easily. The XForms Processor ignores all non XForms markup. 

I was speaking more toward building cross-profile *documents*, not
cross-profile processors. There is no way to build a single generic XForms
document and have it run on either a web browser or a wireless device. You
have to author two documents - one for each host language. The spec doesn't
attempt to accommodate profile independent XForms (that's a statement not a
complaint). 

XForms presentation needs a host language to make it meaningful but XForms
data/logic markup (xforms:model) is meaningful without any host language at
all. The difference is that operations on the data layer are always the same
regardless of host language but operations on presentation are dependant on
host language.

Let's say I have four documents that do the same thing for different
devices: a HTML+XForms, WML+XForms, SVG+XForms, and a HDML+XForms document.
I need all four versions because I want full control over each presentation
language. However, when I want to change a validation rule, I need to make
that change in all four documents. This is unnecessary. There's no reason
for the model definition to be specified in all four documents.

The reason I haven't posted my concern to the www-forms-editor list is
because XInclude will do the job today.

<html>
	<head>
		<xi:include src="shared-model.xml"/>
	</head>
	...
</html>

- Ryan


-----Original Message-----
From: joern turner [mailto:joern.turner@web.de] 
Sent: Thursday, August 29, 2002 6:21 PM
To: Tomayko, Ryan
Cc: www-forms@w3.org; xforms@yahoogroups.com
Subject: 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 23:08:40 UTC