- From: Erik Bruchez <erik@bruchez.org>
- Date: Thu, 5 Feb 2015 08:27:25 +0800
- To: Saad Mansour <me.smansour@gmail.com>
- Cc: "public-xformsusers@w3.org" <public-xformsusers@w3.org>
Saad,
> 1- Since web browsers and mobile operating systems don't support XForms
> natively, so we have to convert the XForm to HTML 5 or to use an engine to
> do that. I wonder that the XForms support more complex forms on the other
> hand we have to convert it to HTML, so why don’t start with HTML?
I think it's a question of going up or down the ladder of abstraction.
XForms is more abstract, HTML less so. Nothing prevents you from using
the lower-level abstraction, if there are good reasons to, but there
are differences between the two.
An analogy, of course a bit faulty because exaggerated: it's a little
bit like saying that, say, C compiles to machine code anyway, and
that's what the CPU runs, so why not write machine code directly? We
tend to like higher abstractions.
> 2- Is there are free engine to convert or run XForms in mobile and browser,
> but how we will handle the validations and etc (I think it is better to
> write our converter)?
I don't understand the question.
> 3- You said that in HTML we have to use a lot of javascript while in XForms
> side there are implementations provide extensions, custom UI components.
> Please, can you explain to me how XFroms provides that or give examples?
XForms doesn't, but XForms implementations do. For example, Orbeon
Forms has an XBL-inspired component model.
> 4- How XFroms provide more submission capabilities than HTML?
For all the details, see the submission module:
http://www.w3.org/TR/xforms/#submit
-Erik
Received on Thursday, 5 February 2015 00:28:12 UTC