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