RE: XForms WD 20011207 - document architecture

Good call, Ryan. :-)

Defining at what point in a containing document XForms elements are allowed
is not a part of the XForms 1.0 spec (even for XHTML).

For every containing document, there needs to be some additional work to
define such things (for instance, XHTML 2.0 will be a biggie). So, in
document types that have a concept of a separate head and body sections, the
XForms 1.0 document provides guidance on how to design the new combined
document type. Obviously, in document types without head/body separation,
the closest approximation needs to be used.

Thanks,

.micah

-----Original Message-----
From: Tomayko, Ryan [mailto:Ryan_Tomayko@stercomm.com]
Sent: Wednesday, December 12, 2001 8:29 AM
To: 'www-forms@w3.org'
Subject: RE: XForms WD 20011207 - document architecture


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

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

- 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
on
>
>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
standards
>
>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
document."

Jim




--
jim@jbrix.org

Visit www.jbrix.org for:
   + SpeedJAVA jEdit Code Completion Plugin
   + Xybrix XML Application Framework
   + other great Open Source Software

Received on Thursday, 13 December 2001 15:22:57 UTC