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

On Mon, Oct 20, 2014 at 4:00 AM, Jarosław Kowalewski <
jaroslaw.kowalewski@students.waw.pl> wrote:

> Steve,
> I cannot agree with you in some points.
>

Hi, I am pleased to hear that you cannot agree, I am playing devils
advocate a little. Trying to make the case that acheiving 'success' (=wide
adoption of a standard) is a function of both technical and human factors.

One the technical side I think that a standard will succeed for one of two
reasons: (1) It provides a platform and so people have an incentive to
decide on one approach (e.g. HTTP); (2) Its a commodity product with little
incentive for individuals to differentiate themselves in the market-place,
so standardise and focus on related services (e.g. browsers somewhat).

On the human factors side people make decisions for a whole host of reasons
(conscious and subconscious), a particularly significant one with software
being 'what everyone else is doing' and for good rational reasons too, like
getting a job to feed your family.

So, I argue that the opportunity to make XForms a true platform passed when
it was not taken up natively within browsers. Imagine if it had, for it to
have become a platform on which to build amazing things, definitely; and
its design fits with the fundamental data-driven design of the browser (a
complex tool to which you feed data input).

This potential that is still there, which is why I think an alternative
browser is still a possibility. But I see it more as an evolutionary branch
rather than to compete with the current lot. I'm still trying to understand
this at the moment, but my interest relates to the web as a web of data,
more than a web of pages.

I don't think I can say too much more as I do mostly agree with what people
have said about XForms, it just seems to me that to much reflection on the
past is not that helpful, better to focus on what to do now. I've just
tried to make the case that human and market factors are just a relevant to
success or failure as technical.

See some comments below.

>
>
> 2014-10-17 23:33 GMT+02:00 Stephen Cameron <steve.cameron.62@gmail.com>:
> > 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.
>
> Yes, unfortunately, Adobe PDFs is more popular solution for big forms
> but I cannot agree with that they  allow anyone to desing forms. If
> you want to prepare simple form of course it's possible. But when you
> need complex forms you have to know what you do. For simple one you
> can use survey monkey too.
>

Agreed, very complex forms cannot be done in PDF, but most of the market I
believe is replacement of paper forms with electronic forms and PDF does
that, people understand the need to make paper forms into electronic ones.

Perhaps we need a common website that gives examples of successful complex
forms projects done with XForms as a marketing exercise? But asking people
to employ someone to edit XML markup is fast becoming a thing of the past.

>
> Other minus is that adobe forms are offline and when user download
> them on the computer you cannot fix bugs as I do quite often after
> release new form.
>

People changing their mind on a form design is an issue, as are bugs. My
interest is more being able to work on completing a client-side form over
several sessions. Doing this with a client-side database to hold model
state makes it very easy to implement. For example doing an electronic tax
return, we have something in Australia called etax, which is an application
that you install, this could be replaced with an EPUB style XForm form.


>
> Plus of PDF form is a print template as default.
>
>
> >
> > (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!
> >
>
> Of course not. It's not possible nowadays to replace xpath by json
> path. Json is just poor brother of xml for simpler situation. I often
> read that xml is to big, you need write more code etc. so why html5 is
> still like xml? Why the standard wasn't rewriten into json for e.g.? I
> think it's possible to write html structure using json notation,
> isn't? I cannot imagine how to manage of big json structures. When at
> the end I see a lot of closing elements without names! It must be
> horrible!
>

All the XML technologies have moved to incorporate JSON as input.

No one was ever meant to write XML or even read it that often (same for
JSON). This is one of the biggest marketing failures of XML, we have at
least one standard for easy editing of XML its called XForms! Now we have
books full of XML markup, when a tree visualisation is so much better.

>
> And again AngularJS form is younger brother of xforms. As I compared
> some solutions for form building I noticed a set of lacks in
> AngularJS. Please tell me how I can use repeat in AngularJS. I can
> simply show list of elements, but how AngularJS supprt:
> - adding, removing elements?
> - adding element based on origin
> - adding new element at position
> - calculation based on mixed context: inside repeat and external data.
>

Here you make a very critical point! This is the unique feature of XForms,
an XML heritage, a good thing to market, don't mention XML though.

>
> In xforms all I need is good knowladge of xpath.
>

I think this statement is too optimistic. When I ask someone to 'buy into'
XForms there is a cost and that is the time to learn it. Its powerful once
you do that, but being declarative you have to learn it properly to make
use of the power (not depend on auto-compilation in an IDE). Same with
XPath.

So we have a situation, I believe, where a good XForms forms design tool
could open up all this declarative power to almost anyone to use, but
programmers editing markup struggle with it once their forms get big. Come
to think of it, IBM developed something along these lines, released a beta
version and then incorporated it into their proprietary product lines.

>
> As I wrote a few days ago I and my coulages prepared more then 2000
> diffrent realy big and complex forms using almost pure xforms, xpath
> and xsd! (FF 3.6 plugin) with full support of calculation, validation
> and user interface.
>

Good news, I am sure there are many examples of similar projects done with
OO platforms too. If you are happy to pay for servers then this option
makes sense to me for many business systems (e.g. to apply for an insurance
policy online). To me, XForms makes more sense in a REST architecture where
things are happening in a more loosely coupled way. For example a scientist
goes out and collects some observation data using an XForms form and then
comes back and uploads that data to a central server, in XRX that data
collection event maintains its independent existence always, as the data
uploaded stays as XML in the database but is a member of a collection of
similar documents comforming to a schema.

>
> The only one thing I need to do is a repeat soriting via xslt.
>
>
> > (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?
>
> But xforms have constraint elements and you can write data related
> validation as in schematron. Of course you cannot validate instance
> data against schematron and only xforms handle validation.
>
> Hiere there is a place for further work and I belive that xforms, xsd,
> xml, schematron need a higher level language to imporve them and
> paradoxically this language should mix all information in one file.
>

Agreed. It makes sense for Michael to do what he is doing, sadly.

Jarek
>