Re: Non-browser compliance

Hi,

Okay Micah, you asked for it!  :)  Here is my $0.2 worth.

As I've been thinking about this, I've been trying to consider four 
examples that cover a wide range of usage scenarios: XHTML, WML, a 
voice-controlled application, and a custom XML application framework. I'm 
familiar with all of these to some degree, and have more extensive 
experience with the latter two.

But before even getting to operational comparisons between XHTML browsers 
and custom applications such as my own (Xybrix), it seems that some (all?) 
of these issues appear even between such similar languages as XHTML and WML.

First: where is does the value in the specification lie? In specifications 
such as SOAP, the value is very clearly in interoperability: multiple 
independent systems on different platforms written in different languages 
can all communicate with each other, and share the same documents, as long 
as they adhere to the specification. In specifications such as [X]HTML, the 
value similarly found, if not necessarily in different applications 
directly communicating with each other, at least in that different 
applications on different platforms are all able to render the same documents.

But with xforms, the goal is much more ambitious in my opinion because it 
is not just cross-application interoperability, but cross-document-type 
interoperability. It's almost like, it's a "sub-spec" that is to be 
included within other larger specs: xforms might be a subset of XHTML, a 
subset of WML, a subset of any other arbitrary custom markup language such 
as my application markup language.  But the applications are ultimately 
processing the outer document as opposed to just the xforms components 
themselves.  To make matters worse, the xforms markup isn't even contained 
in a single unit within its parent container - controls can be interspersed 
amongst non-xforms markup and be rendered in such a way that they are 
functionally tied together.  Example: in an XHTML document, there is XHTML 
markup stating "please fill out this following section if you wish for item 
one to cause item two to occur:" followed by the xforms markup.  A 
completely compliant, non-XHTML xforms processor will render the forms 
controls, but may miss this vitally important piece of markup describing 
the purpose of the form section.

As far as I can tell, as long as there is intertwining of the form markup 
and other client-specific rendering markup, true interoperability is 
difficult to even envision. I've thought about this so much, and it is 
troubling that I can't find the right answer to this question. The fact 
that the xforms are "inlined" to the container document seems fundamentally 
prohibitive of making them application independent in practice: an XHTML 
document must be rendered by an XHTML browser, a VoiceML document must be 
rendered by a voice browser, and so on. These are simply facts. The 
question is, is there any way to make them less intertwined, or would that 
be counter to the very goals that xforms sets out to meet?

Now: in a nice utopian world, best-case-scenario (again, you asked for 
it!), I can see more of a "black-box" container relationship with the 
enclosing renderable document.  Consider how java, flash, SVG, and other 
browser plugins work - the enclosing document specifies where it will exist 
(real-estate-wise) and perhaps passes in some parameters, but then leaves 
the processing to the plugin.

If an XHTML document said, "ok place an xform here, and you can download it 
from here," and then the xform was downloaded as its own independent, 
self-contained unit, then that very same xforms document from the very same 
URL could be re-used by any conforming xforms-capable browser, be it voice, 
WML, custom, etc. The rest of the specification is solid enough to handle 
this.  An organization could have a "forms team" to develop forms 
independent of the whims of any specific presentation markup author. The 
resultant xforms could be definitive "interface" to an organization's 
services - which, in my opinion, is exactly what forms are - a vital 
interface between a user and the services of an organization - much bigger 
in implication that just "a bunch of text fields" as they're all too often 
written off as.  Self-contained xforms documents could also be more 
specific about their lifecycle, an element lacking in the current spec, 
unless I've missed it.  Okay, so your data people build one set of xforms 
as interfaces into the information system, and: your webmasters make XHTML 
pages that point to it, your WAP people make WML that points to it, your 
phone system people make your phone system's voice menu point to it, and so 
on.  THEN it seems you can leverage the true power of xforms.  They are 
written once, by the people who know the information systems, and re-used 
all over, and your users see consistency throughout.  Any xforms-compliant 
app can all plug into these "data interfaces" and the result should be 
predictable operation and results.

I guess, to me, the binding, processing and overall modeling specified in 
xforms seem so tight that I hate to see them cluttered into documents in a 
manner all too similar to their predecessor. I see the importance of xforms 
as more than the specification currently implies.

All of this bears the caveat that I've mentioned before, which is that I 
don't have the benefit of the same experience that the working group has, 
and likely don't understand all the constraints under which this 
development is taking place. These are just my own observations driven by 
my own independent work.

I hope this makes some kind of sense.  I don't know if it is on track, or 
misses the point somewhere, is too idealistic, too late in the spec's 
development cycle, or too impractical.  Take from it what you will!

Please comment.....

Thanks,
Jim


At 02:57 PM 11/7/2001 -0800, Micah Dubinko wrote:
>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 Thursday, 8 November 2001 01:16:52 UTC