RE: XForms WD 20011207 - document architecture

At 11:29 AM 12/12/2001 -0500, Tomayko, Ryan wrote:
>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.

While I certainly agree that specifics are needed to make things compatible 
across implementations, I definitely don't believe that *HTML* specifics 
are the Only Way, OR that it will be vague if it's not in terms of 
HTML.  Why couldn't you say, "model must precede UI controls in the 
document"?  I fail to see why the specific tags "head" and "body" are 
anything but arbitrary, sans that they are exist and are processed by 
[X]HTML browsers in that order.  Is the intent that they are in *those* 
elements, or that they are handled in that order, as has been suggested in 
another post?

For the record I've always acknowledged that [X]HTML will be the "bread and 
butter," and have never suggested otherwise.  And please read my past posts 
to see that in fact, I have argued that *more* specifics are needed (model 
lifecycle guidelines, constraints around containing structures of UI 
controls, etc), not less.  I just think that phrasing them around HTML is 
misleading at best, and constraining *in the wrong way* at worst.  We want 
stable and compatible implementations, not artificial hooks to arbitrary 
markup languages, whether they are "bread and butter" or not.  It's my 
$0.02, take it or leave it.

All that said, your idea about layered specs is the best I've heard in a 
while.  This might be the concept that makes it reasonable to consider how 
xforms could be cross-client.  If a "form" adheres to the core spec only, 
it could be usable across systems, or if it is XHTML specific, a voice 
browser will know not to try to render it.

As it is now, to me as an implementor of a non-"bread and butter" client, 
all of this is moot:  people will be writing this things in-lined into WML, 
XHTML, etc.  And as I said before, until there is an un-intertwining of 
client-specific markup from xforms markup, there is no way to have 
cross-client compatibility, with the exception of microsoft or whoever 
making an XHTML browser that will render WML docs for whatever reason, etc.

I think the intro should include non-goals as many specs do, and state one 
that is: "this is not meant to create stand-alone forms that can be loaded, 
rendered, and processed by different devices," because it can't.  A spec 
that is essentially a subspec means that you will have different versions 
written for different platforms.  There is no reuse across platforms, which 
to me is a very sad thing.  Instead of a single, standalone "purchase 
order" xform document that is referenced in an XHTML, WML, whatever 
browser, and then loaded and rendered by each, you have no choice but to 
make a separate version of the form for every client you wish to support.

I wonder sometimes how much consideration is given to those of us who have 
to support and maintain large systems, where reuse vs maintaining multiple 
versions means tons of time and $$$.

>- Ryan

Jim




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

--
jim@jbrix.org

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 12:16:04 UTC