W3C home > Mailing lists > Public > www-forms@w3.org > December 2001

RE: XForms WD 20011207 - document architecture

From: Tomayko, Ryan <Ryan_Tomayko@stercomm.com>
Date: Wed, 12 Dec 2001 11:29:08 -0500
Message-ID: <5FD6397E455FD4118BAE00062938354002C90202@scidubmsg02.isg.stercomm.com>
To: "'www-forms@w3.org'" <www-forms@w3.org>
IMO, the WG has done a terrific job at balancing the level of separation of
XForms functionality from specific UI markups (considering the pressure they
must be receiving for delivering the next generation of *HTML* [bread and
butter] forms). The fact that the specification lays down rules for use in
XHTML should not be considered a negative aspect of the specification. 

Imagine the implementation incompatibilities you would have if the spec were
more vague in this area. I would argue that further specifics on how XForms
works into XHTML is in order, not less. Further, if other UI markups are to
be supported (WML/HDML/XSL-FO for instance), I would suggest amendments or
sub-specifications that go deeper into implementation details for these

Attacking the inclusion of HTML specific constructs in the spec may be
misguided. Perhaps what is needed is a more layered approach to defining
these constructs. For example, the XForms Core Specification, The XForms
XHTML Spec, The XForms WML Spec, etc.. Perhaps not. At any rate, I find it
unrealistic to assume that this specification could be implemented by
multiple vendors with any kind of compatibility if not for the references to

- Ryan

-----Original Message-----
From: Jim Wissner [mailto:jim@jbrix.org]
Sent: Wednesday, December 12, 2001 11:01 AM
To: JOHANSSON, Justin; 'www-forms@w3.org'
Subject: Re: XForms WD 20011207 - document architecture

At 04:57 PM 12/12/2001 +1030, JOHANSSON, Justin wrote:
>4.3.1. model states:
>"Element model is used as a container for other XForms elements, embedded
>in the head section of other document types such as XHTML. ...."
>Also while not spelt out in the spec, it is implied that the form controls
>themselves are embedded in an element called "body" in the document.
>What's wrong with this is that the spec is imposing a head/body structure
>the document.  That's fine for HTML/XHTML but that's not find for XML
>documents in the general case.  Who says that a valid and well-formed
>XML document must adhere to a head/body pattern?  The XML spec
>certainly does not.  Therefore in constructing a consistent set of
>in which XForms should fit in with XML, the XForms spec should not
>impose such structure on the document itself and there needs to be
>a general purpose XML-ish way of associating the xforms controls
>with the xforms model element.
>Actually I which every XML document did have a head/body structure and
>that would make life easier for everyone.  However XSL documents
>(eg. the W3C XMLspec.xsl) do not have head/body elements.  There
>may be some valid reason for wanting to use XForms in an XSL
>document such as in a web authoring application and such forethought
>should be considered in the XForms spec.

There absolutely is, you are right, or any other non-standard XML 
document.  Any non-html-variant application that wants to leverage re-use 
of forms.  But I'll state again, that while the spec does give a bit of 
service to other clients such as voice browsers, there are enough hints of 
HTML to suggest it's still biased strongly this way, and that there hasn't 
really been a complete clean-slate approach that would be free of these 
kinds of "idiosyncrasies."  Yes, they are covering the bases of the largest 
likely potential platforms, but they are also (IMHO) making it in such a 
way that it resists breaking free into new kinds of interfaces.

Anyway, I won't go over all of my previous issues again, but I'll just say 
I agree with you 100%, and the problem you cited isn't the only one in the 
spec that would present problems to a "non-head/body structure XML



Visit www.jbrix.org for:
   + SpeedJAVA jEdit Code Completion Plugin
   + Xybrix XML Application Framework
   + other great Open Source Software
Received on Wednesday, 12 December 2001 11:32:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:05 UTC