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

All,

I have been following this thread with interest... In my opinion some of
the use-cases that XForms was initially trying to solve are less of an
issue today - e.g. portability across environments, poor forms support in
HTML4 and mobile forms.

Having said that I agree with Jaroslaw in that I still believe there are
some (perhaps niche) complex use-cases where the power of XForms is still
required. Further I think that XForms and JS equivalents such as Angular JS
should only be directly compared - the full complementary set of
technologies and specifications should be considered.

For instance in my current project I need to be able to:

(1) Ensure full portability - e.g. Import/Export forms between products.
Standards often provide the best mechanism to achieve this. Also (in an XML
world) where there a product specific extensions these can often be managed
via simple XSLTs to ensure any richness is not lost.
(2) Be able to modularise form - i.e. assemble larger forms from subforms /
building blocks - here XSLT also provides the necessary pre-processing
power.
(3) To add global behaviour and rules to forms (XSLT).
(4) To be able to examine the rules and bindings of a form to generate
derivative products - e.g.
(4.1) use XSLT and XPath to generate a XSL:FO pdf templates following the
same structure as the form (see
http://fhirforms.com/XFormsPDF/XFormsPDF?formName=Resus for an example
output)
(4.2) or derive schematrons using the rules embeded in the form.

I for one would welcome the JS/JSON world providing equivalents to some of
these XML technologies (to me syntax does not matter), however as it stands
I don't want to discard all my power tools until I have suitable
replacements.

Michael


On 17 October 2014 12:38, Stephen Cameron <steve.cameron.62@gmail.com>
wrote:

> Attempting to answer my own questions:
>
> (1) Is there still a market niche for XForms as it stands?
>
> Its occurred to me in the past that XForms still has potential for wide
> use by becoming something like EPUB. That is to make it a replacement for
> paper forms that can be filled in offline, that is as a competitor to Adobe
> forms. This would take advantage of the new database capabilities of
> browsers to store model data for later submission.
>
> (2) Can XForms evolve to serve this new (apps) need and if so can anyone
> be bothered, given the head start of others.
>
> Not a chance.
> XML was never meant to be a programming language.
> There are no tools for designing XForms forms, I've built a tool to
> generate complex ones, but that is a different use-case, it hides XML from
> non-programmers.
>
>
>
> On Fri, Oct 17, 2014 at 11: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.
>>
>> The current need is to be able to create 'apps' in browsers.  To take the
>> cross-platform low-cost browser approach and create app levels of
>> functionality. The browser as something for browsing has been extended, the
>> 'write once, run anywhere' and 'network programming' concepts that Java
>> introduced have been taken up by browsers as HTML5.
>>
>> I think simply that the XForms standard is of the old browsing paradigm
>> and AngularJS is of the new app paradigm. This is why I've argued that its
>> not helpful to think of XForms as MVC, which is an OO concept, whereas
>> browsers without Javascript are a data-driven approach.
>>
>> So the testable hypotheses IMHO, are: (1) is there still a market niche
>> for XForms as it stands? and (2) can be XForms evolve to serve this new
>> need (and if so can anyone be bothered, given the head start of others).
>>
>> On top of these questions you have to ask also if free and open-source is
>> now being challenged by Software as a Service (SaaS). The browser as app
>> platform is key to SaaS, and the economics of it are so compelling for
>> consumers that it challenges everything, in much the same way that Mobile
>> apps did for browsers. Forms are just one part of that. The key driver of
>> SaaS is not functionality but convenience I believe, so the software is
>> essentially free and you pay for the fact your data is managed and easily
>> accessible.
>>
>> Steve
>>
>> On Fri, Oct 17, 2014 at 6:55 AM, Ihe Onwuka <ihe.onwuka@gmail.com> wrote:
>>
>>> So that begs the question.... why reinvent the wheel and when I ask that
>>> why I mean why totally throw out everything (like they did with XML) and
>>> start from scratch.
>>>
>>> It seems to be a very arrogant way of doing things . to say there was
>>> nothing good in what the other bloke did.....especially when it is the case
>>> that when you listen and scrutinize what they say carefully (I mean the
>>> JSON crowd) it doesn't hold water.
>>>
>>>
>>>
>>> On Thu, Oct 16, 2014 at 7:21 PM, Paul Vanderveen <
>>> pvanderveen@terraxml.com> wrote:
>>>
>>>>  FYI.  AngularJS is a declarative framework as well – conceptually
>>>> very similar to XForms
>>>>
>>>>
>>>>
>>>> *From:* William Velasquez [mailto:wvelasquez@visiontecnologica.com]
>>>> *Sent:* Thursday, October 16, 2014 10:21 AM
>>>> *To:* ihe.onwuka@gmail.com; Manuel Lautenschlager
>>>> *Cc:* Paul Vanderveen; xsltforms-support@lists.sourceforge.net; Forms
>>>> WG; public-xformsusers@w3.org
>>>> *Subject:* RE: [Xsltforms-support] Is XForms a failure to learn from?
>>>>
>>>>
>>>>
>>>> Ihe Onwuka wrote:
>>>>
>>>>
>>>>
>>>> > To me XForms's biggest crime is that it is a declarative technology
>>>> (yes it can be  complex but so are lot's of over things) and alot of
>>>> programmers are not comfortable with something that is not inherently
>>>> procedural. Heck they even created languages to proceduralize SQL the only
>>>> declarative language that managed to slip under the cover.
>>>>
>>>>
>>>>
>>>> Excellent point!
>>>>
>>>>
>>>>
>>>> And most of the XML tools are declarative too (XSLT, XProc, Schema
>>>> languages) so the “XML-phobia”  can be explained as “declarative-phobia”.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *De:* Ihe Onwuka [mailto:ihe.onwuka@gmail.com <ihe.onwuka@gmail.com>]
>>>> *Enviado el:* jueves, 16 de octubre de 2014 10:51 a. m.
>>>> *Para:* Manuel Lautenschlager
>>>> *CC:* Paul Vanderveen; xsltforms-support@lists.sourceforge.net; Forms
>>>> WG; public-xformsusers@w3.org
>>>> *Asunto:* Re: [Xsltforms-support] Is XForms a failure to learn from?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Oct 16, 2014 at 3:46 PM, Manuel Lautenschlager <
>>>> Manuel.Lautenschlager@ascio.com> wrote:
>>>>
>>>> What is lightweight?
>>>>
>>>>
>>>>
>>>> For me lightweight is: Parsing takes only little resources.
>>>>
>>>>
>>>>
>>>> I'm not sure why we are bothering about how much work the machine does
>>>> unless we have a specific performance problem so I smell a red herring here
>>>> ....but ..... doesn't that depend to extent on what you are running in your
>>>> environment.
>>>>
>>>> If you are running Python or R or anything other than javascript in
>>>> addition to your interpreter you also have to load a JSON library.
>>>>
>>>>
>>>>
>>>>
>>>>  Implementation is easy with a few lines of code. Only necessary
>>>> functionality.
>>>>
>>>>
>>>>
>>>> Well that depends on whether one believes that transformation's are
>>>> necessary functionality because (discounting the efforts of the XML
>>>> community i.e xslt3 json doesn't have a proper transformation language).
>>>>
>>>> It also depends on whether one believes that a query language is
>>>> necessary because (discounting the efforts of the XML community i.e jsoniq)
>>>> json doesn't have a proper query language.
>>>>
>>>> So what is left of that argument..... that being able to do sod-all is
>>>> a virtue. Nah! Rather you have to write an application program for
>>>> everything - we've known for 35 years (at least) that's a bad idea. For one
>>>> thing it destroys data independence because people will tend to tightly
>>>> couple their code to the extant data model (if for no other reason then the
>>>> obsession with "efficiency").
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>  Not lightweight is: Very complex framework that tries to cover
>>>> everything.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> The fallacy in there is that because the framework allows you to "cover
>>>> everything" you have to. That's not true. There is no rule that says your
>>>> XML must have a schema. There is nothing stopping you from writing a
>>>> transformation to create a simpler XML subset if it will do the job.
>>>>
>>>>
>>>>
>>>>
>>>>  I’m sure XML needs a few more lines to implement than JSON.
>>>>
>>>>
>>>>
>>>> It's a semantically  richer data format, that's not unreasonable.
>>>>
>>>>
>>>>
>>>>  But what really is heavyweight are many standards. Like SOAP and
>>>> XFORMS.
>>>>
>>>>
>>>>
>>>>  The JSON world doesn’t have this problem, they don’t have  standards
>>>> like XForms. (And no alternative)
>>>>
>>>>
>>>>
>>>> The heavyweight lightweight thing is because  JSON  world is probably
>>>> occupied with comparatively trivial data models. Murex, XBRL, Biztalk, UBL
>>>> are not suddenly going to become lightweight if they were converted to
>>>> JSON. But the real fallacy is that something implemented in XML is
>>>> necessarily complex or heavyweight. Suppose you don't need schemas for a
>>>> particular JSON implementation. Chances are you wouldn't need them for an
>>>> XML implementation either but if ever you did in the future you won't find
>>>> that you have taken a long journey up s**t creek and thrown away your
>>>> paddle.
>>>>
>>>> XForms is a ambitious . It's complexity is not a function of the data
>>>> model and one is  not compelled to use every facility in the standard.
>>>>
>>>>
>>>>
>>>>  You don’t need to learn how to use XForms. You need a form, you can
>>>> start right on with a language you know (Javasript)
>>>>
>>>> People use other libraries to create forms, like AngularJS, and have a
>>>> handmade component for each control.
>>>> Actually every developer/company has its own UI-Style, and so they can
>>>> create the Framework they need.
>>>> Often it’s only small things that XForms can’t do. Like working with
>>>> Websockets. Interactive status for an order form.
>>>>
>>>>
>>>> With XForms the standard tells you how to work. With that you always
>>>> have limitations.
>>>>
>>>> I accepted these limitations with the benefit that I am working with a
>>>> standard.
>>>>
>>>> That “should” mean: sustainability, better support and documentation,
>>>> many different applications you can run your code on.
>>>>
>>>>
>>>>
>>>> Unfortunately the reality is, that people are talking about dead
>>>> standards, just when I am happy with them.
>>>>
>>>> I must say it took a while until I got used to XForms. For me that was
>>>> investing lots of time.
>>>>
>>>>
>>>>
>>>> I used Betterform, which is the opposite of lightweight. But it is
>>>> cool. The disadvantage is: When you work with the XForms language,
>>>>
>>>> It’s a big step adding new components and scripts. This is much easier
>>>> when you build up your UI from scratch.
>>>>
>>>>
>>>>
>>>> Are you sure that's a problem caused by the XForm standard. I recall
>>>> that when I built an XForm I was able to modularize much of the code and
>>>> the ability to deploy XSLT transformations was a key part of that.
>>>>
>>>>
>>>>
>>>>  That is the problem with standards that cover almost everything. You
>>>> get used to it, and try to do everything with the standard.
>>>>
>>>> Otherwise you can’t port it to another platform.
>>>>
>>>>
>>>>
>>>> BTW. Just because somebody of W3C says it’s dead, it doesn’t need to be
>>>> dead or a failure. But except of the XML-Community, nobody knows XForms.
>>>>
>>>> I like XForms and I hope that it’s not dead!
>>>>
>>>>
>>>>
>>>> Manuel
>>>>
>>>>
>>>>
>>>> Ps.: When tools can do less, you need to learn less. That why people
>>>> use JSON
>>>>
>>>>
>>>>
>>>> Being able to do sod-all is only a virtue if you actually need to do
>>>> sod-all.
>>>>
>>>> I think most of the claims emanating from the JSON community do not
>>>> withstand scrutiny or like for like comparisons. To me XForms's biggest
>>>> crime is that it is a declarative technology (yes it can be  complex but so
>>>> are lot's of over things) and alot of programmers are not comfortable with
>>>> something that is not inherently procedural. Heck they even created
>>>> languages to proceduralize SQL the only declarative language that managed
>>>> to slip under the cover.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Comprehensive Server Monitoring with Site24x7.
>>> Monitor 10 servers for $9/Month.
>>> Get alerted through email, SMS, voice calls or mobile push notifications.
>>> Take corrective actions from your mobile device.
>>> http://p.sf.net/sfu/Zoho
>>> _______________________________________________
>>> Xsltforms-support mailing list
>>> Xsltforms-support@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/xsltforms-support
>>>
>>>
>>
>


-- 
--
Michael Odling-Smee | mike@xml-solutions.com | m: +44 (0) 7946 512 754 |
www.xml-solutions.com

This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind XML Solutions ltd to any order or other contract unless pursuant to
explicit written agreement or government initiative expressly permitting
the use of e-mail for such purpose.

Address: XML Solutions ltd, 30 Claremont Road, Headingley, Leeds, LS6 4EB.
UK. Registered Company Number: 6233174