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

RE: XForms WD 20011207 - document architecture

From: Micah Dubinko <MDubinko@cardiff.com>
Date: Thu, 13 Dec 2001 13:54:43 -0800
Message-ID: <E840F0B7E6189547BDB91DA8BF2228AB28C087@csmail.cardiff.com>
To: "'Jim Wissner'" <jim@jbrix.org>, "'www-forms@w3.org'" <www-forms@w3.org>
What I mean is that XForms 1.0 doesn't provide the necessary "Modularization
of XHTML(tm) in XML Schema" (or the equivalent for SVG/XSL/etc.) pieces
needed to define an overall markup language.

An example of something along these lines is the HTML+SMIL profile

I expect similar for various combinations of XForms with other languages. It
is a form of layering brought about by necessity. It's easy to imagine
XForms integrated with some new markup language that doesn't exist today.
Until time travel technology improves, that sort of thing will never make
XForms 1.0. ;-)


-----Original Message-----
From: Jim Wissner [mailto:jim@jbrix.org]
Sent: Thursday, December 13, 2001 1:42 PM
To: Micah Dubinko
Cc: www-forms@w3.org
Subject: RE: XForms WD 20011207 - document architecture

At 12:21 PM 12/13/2001 -0800, you wrote:
>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

Can you explain what you mean here?  By "define" do you mean explain, or do 
you mean there will be constraints in the spec that will need to be 
followed?  And, if there will be additional constraints in the spec for 
specific markup languages, what does this mean for non-standard 
containers?  Is this the layered spec approach that Ryan spoke of?


>document types that have a concept of a separate head and body sections,
>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.
>-----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
>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
>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
>- 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
> >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


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 16:56:13 UTC

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