W3C home > Mailing lists > Public > www-forms@w3.org > August 2002

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

From: T. V. Raman <tvraman@us.ibm.com>
Date: Fri, 30 Aug 2002 14:57:54 -0700
Message-ID: <15727.60002.891914.982832@bubbles.almaden.ibm.com>
To: "Tomayko, Ryan" <Ryan_Tomayko@stercomm.com>
Cc: joern turner <joern.turner@web.de>, www-forms@w3.org, xforms@yahoogroups.com


good point.
Not only  will xinclude help here --simple perl script on the server
that stitches things together is what the average apache hacker is
likely to use --rather than wait for the standards world to specify a
solution.

Ultimately, there are standards, there are implementations of
standards, and the deployment of standards.

Given how long it takes to get a standard developed and signed off on,
it's a good thing that working groups dont also fall into the hole of
specifying how one deploys the technology;
think how long it would take to develop Apache 0.1 if this weren't the
case:-)

>>>>> "Tomayko," == Tomayko, Ryan <Ryan_Tomayko@stercomm.com> writes:

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

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

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

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

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

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

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

    Tomayko,> - Ryan


    Tomayko,> -----Original Message----- From: joern turner
    Tomayko,> [mailto:joern.turner@web.de] Sent: Thursday, August 29,
    Tomayko,> 2002 6:21 PM To: Tomayko, Ryan Cc: www-forms@w3.org;
    Tomayko,> xforms@yahoogroups.com Subject: Re: XForms Reusability /
    Tomayko,> Modularization (was RE: XForms WD 20020821 - 2.1 XForms
    Tomayko,> and XHTML etc)


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

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

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

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

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

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

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

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

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

    Tomayko,> i'm currently working along the following lines.

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

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

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

    Tomayko,> 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
    Tomayko,> 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:58:17 GMT

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