RE: Non-browser compliance

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