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

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