Re: HTML forms, XForms, Web Forms - which and how much?

On Apr 26, 2007, at 5:21 PM, Mark Birbeck wrote:

> In XForms, we have a one or more models of data, and then zero or more
> controls that can 'bind' to the data. The processing sequence is quite
> clearly defined in that each model is to be initialised in turn, all
> of the controls that are bound to a model are to be sent events,
> refreshed, etc., etc. But whilst the spec is very specific about that
> kind of thing, it doesn't say 'use XPath to go find the controls' or
> 'use the DOM to go find the controls', or whatever. In other words, an
> implementation obviously has to find the controls, since if it doesn't
> it can't initialise them. But how it finds them is up that
> implementation, since how an XForms processor that is split between a
> server and web-browser does it will be different to an XForms
> processor that is running embedded in a .NET application, and
> different again from a Java-based client running in a mobile phone.
>
> That's all I was getting at. :)

Obviously it shouldn't specify the implementation of what form  
controls are found. But does it guarantee to authors which specific  
*set* of form controls will be found? If not, how can you write  
XForms code that is interoperable between multiple implementations?

>> XMLHttpRequest is not an XML application. "XML application" means a
>> specific vocabulary that uses XML syntax.
>
> That's right. So XForms is not really an XML application since it
> cannot exist outside of a host language.

 From the XForms spec, first line in the Abstract: "XForms is an XML  
application that represents the next generation of forms for the Web. "

And I think this claim is correct, it is indeed an XML application in  
the sense of a vocabulary for use in XML documents.

> And as I've shown it is easily hosted in non-XML vocabularies.

Such use may be interesting, but is not defined by the spec.

> However, the reason I said 'it depends what you mean', is that some
> people have described XForms as being XML-only because one of its
> goals is to make processing of XML easier. I was simply saying that as
> XMLHttpRequest shows, components that handle XML need not themselves
> be running in XML applications.

XMLHttpRequest is an API, not a language - the two are not at all  
parallel. You don't have to embed XML markup in HTML to use  
XMLHttpRequest.

>> > The same goes for XForms. Regardless of whether it has been  
>> believed
>> > or claimed that it was a language that was only for XML host
>> > languages, the reality is that it is being used today by lots of
>> > people, in an environment that is essentially HTML.
>>
>> Perhaps this non-XML use is worth writing a spec for, then, so that
>> it can be implemented interoperably by more than one user agent.
>
> That's true. I don't think a lot needs to be added, since XForms is
> very precise about its processing model. But the use of things like an
> attribute on an HTML element that looks exactly like an XML namespace
> attribute is obviously quirky, and would need defining.
>
> But we digress. :)

I hope we can agree that XForms does not define how to use XForms in  
non-XML HTML. Whether doing such a thing is desirable can be debated,  
but there is definitely no spec for it.

Regards,
Maciej

Received on Friday, 27 April 2007 00:38:22 UTC