RE: Non-browser compliance

Jim,

Could you provide a "best-case-scenario" for how XForms (and XForm
conformance) could be specified to allow both innovative applications (like
yours) and regular browsers to be conforming and interoperable (and not just
in words, but in practice)?

.micah

-----Original Message-----
From: Jim Wissner [mailto:jim@jbrix.org]
Sent: Wednesday, November 07, 2001 9:17 AM
To: www-forms@w3.org
Subject: Non-browser compliance



Hello,

Ok, please bear with me on this.

It seems that there is reasonable demand for true w3c xforms compliance by 
the users of my software. I've been studying the specification for some 
time now and have drawn some interesting conclusions. Perhaps the most 
striking thing, at least from the point of view of trying to make my 
application framework w3c xforms complaint, are the constraints (or lack 
thereof) placed upon the "containing document".  From the spec, a 
containing document is "A specific document, for example an XHTML document, 
in which one or more <xform> elements are found."  Sounds straightforward 
enough. But in practice it has some serious implications.

While it doesn't specify what should be in the rest of the doc, there is an 
underlying assumption that there will be other renderable markup: ie, as 
with XHTML or WML.  That is, there will likely be textual markup frequently 
if not always surrounding the form controls themselves in the same 
document, that (and this is the important part) can alter the intent and 
behavior of the xforms themselves.  The items of the spec are indirectly, 
but heavily, impacted by content outside the scope of the spec.  Contrast 
this to somethinglike SOAP where the container and containing structure, 
the lifecycle, etc are much more rigorously defined. The fact is, if an 
xform that is created for an XHTML page is loaded into a Xybrix application 
(my app framework), vital information will very likely be lost. Likewise, 
an xform designed in Xybrix will not even load in a web browser.

So you can see how two applications (Xybrix and a web browser) could 
potentially both be 100% xforms compliant, and yet be unable to read and 
render the same documents.

I must strongly emphasize that this is *not* a complaint of the w3c's 
xforms specification. The fact that it is geared towards xforms largely 
being processable content embedded within "web-style" browser-loadable 
documents (XHTML, WML, etc) is quite obviously because that will make up 
the vast, vast majority of use it will see.  The hole it is trying to fill 
is quite evident, and in my opinion it is very good specification that 
meets this goal very well.  As a side note, I think it might be a 
worthwhile addition to the spec to point out some of these things to the 
potential implementor, rather than, as it is now, making it seem more 
"container independent" than I believe it really is.  It's more of, "this 
KIND of container independent."

So all of this begs the question: why bother conforming?  Should a 
non-browser application adhere to this spec?

This is what I struggle with, before fully embarking upon it.  Any comments 
are greatly, greatly welcomed.

Thanks,
Jim

Received on Wednesday, 7 November 2001 17:58:26 UTC