W3C home > Mailing lists > Public > public-html@w3.org > April 2007

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

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Fri, 27 Apr 2007 01:21:14 +0100
Message-ID: <640dd5060704261721k765ed749p53d361fe3d359e4e@mail.gmail.com>
To: public-html@w3.org

Hi Maciej,

> > Well, for better or worse, the XForms processing model doesn't define
> > how processing is 'kicked off'. It's quite precise about what happens
> > once the XForms processor is initiated, though, but even then its not
> > prescriptive about things like how to find all controls that relate to
> > a given model. So although it says that all controls for a model must
> > be initialised at a certain point, it doesn't say how to find them.
> >
> > This of course gives us the best of both worlds; a clearly defined
> > processing model, without being prescriptive about host language,
> > parsing, and so on.
>
> Not specifying basic things like how to find the controls doesn't
> sound like the best of both worlds, it sounds underspecified. So I
> hope I am missing something. Authors need a consistent guarantee for
> how their controls will be found.

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


> 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. And as I've shown it is
easily hosted in non-XML vocabularies.

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.


> If you do bubble and capture phases together across multiple
> documents for the same dispatch, then yes, this is wrong, in that it
> violates the DOM 2 Events spec. I'm not sure if this is what you had
> in mind. It might be that what you describe is merely not
> standardized, as opposed to contrary to a web standard.

No, I'm merely saying that the target of a dispatched event might not
be in the same DOM tree as the originator. And similarly, it is
possible to register for events running in completely different
processes, as well as for system events.


> > On the one hand, you could say that this is a bad thing because a
> > window is not a DOM
> > element, so what's it doing being an event target for DOM 2 Events?
>
> DOM 2 events does not require event targets to be Elements or even
> DOM Nodes. But it does have requirements on how bubble/capture happen
> in the DOM.

Right.


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

Regards,

Mark

-- 
  Mark Birbeck, formsPlayer

  mark.birbeck@x-port.net | +44 (0) 20 7689 9232
  http://www.formsPlayer.com | http://internet-apps.blogspot.com

  standards. innovation.
Received on Friday, 27 April 2007 00:21:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:15:53 GMT