- From: Maciej Stachowiak <mjs@apple.com>
- Date: Thu, 26 Apr 2007 16:59:54 -0700
- To: mark.birbeck@x-port.net
- Cc: Henri Sivonen <hsivonen@iki.fi>, public-html@w3.org
On Apr 26, 2007, at 4:44 PM, Mark Birbeck wrote: > > Hi Henri, > >> Is there a specification that explains the processing model for >> XForms in text/html in a way that is interoperable with IE >> +formsPlayer? > > 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. >> > There is actually nothing about XForms that says it >> > must be delivered in an XML-based language. >> >> That's a bit of a stretch considering that XForms is defined to be >> "an XML application". > > I guess it depends what you mean by that. You can use XMLHttpRequest > in an HTML document, can't you? XMLHttpRequest is not an XML application. "XML application" means a specific vocabulary that uses XML syntax. > In my view, XForms can be seen as much > the same thing; a powerful processor that can be incorporated into > some host document/application to do all sorts of clever stuff. This > could range from simple forms, through to complex desktop > applications. > > At the end of the day, all of this stuff is about implementation. For > example, one of the other products my company has built is called > Sidewinder, and it allows you to create desktop applications using web > standards. We allow events to be dispatched from one window to > another, using DOM 2 Events...is that wrong? 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. > 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. > 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. Regards, Maciej
Received on Friday, 27 April 2007 00:00:05 UTC