Re: XForms WD 20011207 - document architecture

Hello,

although i consider the spec basically a great work especially for it's 
vision of client-independency but there are reoccurring problems when 
trying to implement things.

i strongly agree that the constraints that are put on XForms mainly 
emerge from its close relationship to html. of course, examples with use 
(x)html open the door to XForms for web-authors/designers (which is a 
good thing). but i don't see any reason why XForms shouldn't be used on 
any other platform/protocol with enourmous gain. currently it's 
impossible to implement a multi-client XForms processor without making 
your own extensions (thereby limiting the scope for 'standard' XForms 
unnecessarily).


Jim Wissner wrote:

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


Although i think a 'layered' approach generally a good idea (cause there 
  *are* platform/client specifics) this maybe too ambitious for a 1.0 
version. these might develop later.

it would be a great improvement to extend the spec. to support 
'standalone' and/or 'embedded' forms. the standalone variant would 
define a complete XForms document (without making references to html) 
for use in a multi-client environment while the 'mixed' variant may be 
used for projects with lower requirements (also: although only one 
client xhtml may support multiple clients).


[edited]


> 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 strongly agree. as stated from other listmembers earlier, the mixing 
of markup makes things significantly more complex cause surrounding 
markup may alter the XForms semantics or worse relies on it. in this 
case clients are highly coupled to this platform.

although still possible to implement i would agree that it is nearly 
impossible to do so in a modular fashion.


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


a listing of non-goals would really be helpfull for shaping XForms 
implementations.

also i would strongly argue for *one* spec. a XForms document should be 
expressable as a client-independent representation, otherwise it may 
reach its goal as html successor but it could be so much more. it would 
be bad to hack all this to pieces.

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


Joern

Received on Wednesday, 12 December 2001 19:10:48 UTC