- From: Jim Wissner <jim@jbrix.org>
- Date: Thu, 08 Nov 2001 10:04:05 -0500
- To: "David E. Cleary" <davec@progress.com>
- Cc: www-forms@w3.org, Micah Dubinko <MDubinko@cardiff.com>
Hi, At 09:22 AM 11/8/2001 -0500, you wrote: > > 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. > >XForms can easily be split into two parts, the form purpose and the form >presentation. The presentation side of the equation isn't tied to any >particular vocabulary. You can bind a form to XForms widgets, XHTML widgets, >WAP widgets, or a proprietary vocabulary. Obviously, the presentation >vocabulary you choose is dependent on the client being able to render it. >However, the pupose of the form does not change at all. > >If Xybrix doesn't support (X)HTML, then, people shouldn't expect it to >render it. Same goes in the other direction. But this is be design. > >David Cleary This I understand. But the question really is: how is it used in practice, and where is there any re-use in practice (and thus justification for compliance by a non-browser)? As I've stated, I believe the "form purpose" part of the spec has succeeded in being very solid and independent of presentation - it was indeed well designed. But look at the spec as a whole. When I read it, I see no practical example scenarios of how these two parts are deployed independently. I see no mention of a hypothetical "xforms-purpose-document" server that is able to be distribute models to multiple presentation-independent clients. What I am saying, is this seemingly benign statement "the presentation vocabulary you choose is dependent on the client being able to render it" is in fact profound in its implications to how much xforms conformity buys the implementing application. If indeed the most common case *in practice* will be that the "purpose" and "presentation" parts of the xforms are bundled together, then they are not cross-client, because as you have correctly stated, the markup for one type of presentation client is just for that kind of client. If they are that tightly tied together then you have effectively made xforms a part of each individual markup language, and as near as I can tell there is not much incentive to not add significant non-conforming extensions. Let me state: if this is NOT how it is intended to be in practice, then I will happily rethink the issue. But it certainly does not come across in the spec. To be sure, there is no doubt about the separation of purpose and presentation. But I'm not talking about concept in a spec I'm talking about *in practice*. I'm talking about implementing the spec in real life. From the point of view of implementing it as a part of some browser, fine. But I challenge anyone who has implemented this spec to any degree to see if in fact they can separate their presentation markup from the purpose sufficiently enough to author xforms purpose components and deploy them independent of their markup language of choice. Because if I can conform by just implementing the "purpose" parts of the spec, then I can just keep my own presentation methods, keep my custom widgets, and forget about the controls portion of the spec. But then do I really know enough to render an interface without presentation markup? So, to give the benefit of the doubt, let's say a company DOES manage to deploy the "purpose documents" independent of the presentation docs. Can I hit them with my custom application, or do I have to go through their authored XHTML or WML pages? If the latter, and I can't see otherwise the way it is, then how is this not effectlively the same writing on the wall for me as a non-XHTML application developer? It's not gonna work anyway!! Perhaps I come too strongly from a point of view biased to *towards* system interoperability with things like SOAP, etc where you can talk through very tight interfaces, than through browsers, which in my humble opinion are constraining peoples outlook on things when we should be REALLY taking clean-slate approaches. I guess I'm just naive! :) I just think xforms are "user/data" interfaces that merit stronger specification constraints than is the case with highly subjective markup such as [X]HTML. Then you'll really be able to see multiple devices interface into your data systems. Anyway, these are not just idle gripes, please understand. I fully acknowledge I may be missing something. But it seems that where the spec has succeeded in some of its theoretical goals of making a nice design separation between components, it has a way to go to being something that stands strongly on its own and can give a third-party, objective application implementor a clear roadmap to building something they can confidently say adheres to the spec *and* have that mean something *other* than saying they adhere to the spec. Right now, other than the fact that I think what is there is very good, I don't see convincing evidence to make my custom XML application framework compliant. Which brings me right back to my original questions: why would someone other than a browser-maker implement it, if in practice it will be authored in a way that it is intertwined with XHTML/WML/etc? Thanks, and I hope I don't come across as anything other than respectfully inquisitive, Jim
Received on Thursday, 8 November 2001 10:01:13 UTC