Re: [Xsltforms-support] Is XForms a failure to learn from?

Does is serve a need?  Mark Lawson and Michael Odling-Smee suggest it still
does that well for them, however:

(1) Replacing paper forms

Yes, but Adobe PDF forms have been selected as the electronic forms
standard by the Australian Government, but as I suggested XForms could now
compete with an offline capability. The two main needs the PDF forms do
handle well are allowing anyone to design forms and a server side data
handling package, both of which earn money for Adobe.

Also SaaS is throwing up many online forms services now.

(2) Forms can be composed using XSLT

Yes, but so can almost anything really, as Alain has demonstrated with
XSLTForms (XML translated to Javascript). I'm sure its possible to generate
AngularJS markup, its declarative too!

(3) Declarative validation and business rules.

Michael Odling-Smee does XForms to Schematron rules translation, that is a
bit strange, why not the other way around? XForms does not understand
Schematron. Someone has done a PhD on XML Schema to XForms
translation/integration, where is that project now at commercially?


I am not saying Mark and Michael are wrong at all, just that in trying to
convince someone to use XForms there are still issues.

For application developers, the forms part is a component, and simple web
forms are easily done in most web frameworks. A bigger issue is business
logic in the server side. To say that XQuery is the best language for
implementing this, as part of the XRX package, is where the main debate is
IMO.

Steve



On Sat, Oct 18, 2014 at 1:44 AM, Ihe Onwuka <ihe.onwuka@gmail.com> wrote:

>
>
> On Fri, Oct 17, 2014 at 1:00 AM, Stephen Cameron <
> steve.cameron.62@gmail.com> wrote:
>
>> My point is this: for something to be a success it needs to serve a need,
>> so that need has to exist or you have to create it via marketing. AngularJS
>> does both.
>>
>
> That's an awfully low bar, A thing of less than 5 years vintage is being
> declared a success!?  As many NoSQL vendors (because they mix too many bad
> ideas in their products) will soon discover it is not enough just to be
> "NOT" something (whether that something is SQL or XML).
>
> Genuine paradigm shifting events in IT come few and far between and when
> they do come they aren't usually coated in the flavour of the implementors
> favourite programming language. Often they result from a belated
> realisation that a historical solution (ignored because of "poor marketing"
> or technological limitations of the day) got the fundamentals and is in
> fact the right solution.
>
>
>
>

Received on Friday, 17 October 2014 21:34:14 UTC