- From: Joern Turner <joern.turner@betterform.de>
- Date: Fri, 17 Oct 2014 09:03:52 +0200
- To: "<public-forms@w3.org>" <public-forms@w3.org>
Stephen, Am 17.10.14 02:00, schrieb Stephen Cameron: > 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). (1) i definitely think there's a niche market. There are lots of big XML-based document standards out there e.g. AIXM (air information) or HL7 (ehealth) which are both complex and big. The niche is probably not really that small as these applicaton are numerous and growing. But they surely fly under the radar when looking at typical frontend technologies. Why? I don't really want to implement such a standard with a technology like Angualar - no, thanks. With XForms we've build a form generator that turns 1.3megs of raw schema into about 300 different complex forms. So where it really gets complicated XForms has its place. But that niche is not necessarily feeding much people. (2) I'm here with Ihe - we shouldn't throw away the (huge) work that has been done already. After having implemented XForms for more than a dozen years i'm certainly not motivated to consider this all a failure but i'm also increasingly unhappy with the standard as it is. At betterFORM we started to think about separating the good from the bad about 2 years ago and slowly we get to a picture of the (our) future. Consider the different parts: - the model: IMO the powerful heart of XForms. This is where i can annotate data with constraints and express dependencies between data items. It makes sure everything stays in the loop and is consistent all the time and does so in an efficient manner. - submission - though part of models can be considered a separate module. These can be handy as they allow a lot of control when loading, writing and manipulating data. - UI - well yes. The abstract UI was a fantastic idea back then when it was invented (remember that's already more than 10 years) and a variety of devices began slowly to rise up. So an abstract UI that is transformed into what the device 'speaks' seemed like a very good idea. Now it happened that HTML took over the world and browsers are available nearly everywhere. So when in 10 years i never had the use case of using something other than HTML as target format how much sense an abstract UI still makes? None. - Actions - the procedural part of XForms that pretends to be declarative. Again - back then the idea could attract but essentially procedural routines written in XML ... No. Has never worked or been too ugly that anybody like to use them. Living in the browser as the natural environment a JavaScript API would have done better. But probably most important - XForms ideas still can be useful and survive if we transport them into todays' world. And this means essentially than it must become much easier and 'natural' to use XForms facilities. Btw, i don't see any value in JSON vs. XML discussions. This is comparing 2 very different things each of them having it's pro's and con's. But i see no reason why a modernized XForms Model processor shouldn't support JSON and XML. We did some prototypes and it's not that hard. > > 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 <mailto:ihe.onwuka@gmail.com?Subject=Re%3A%20%5BXsltforms-support%5D%20Is%20XForms%20a%20failure%20to%20learn%20from%3F&In-Reply-To=%3CCAG%3Dut6LGivacoj28LHfcViNhA238LfA0%3DmUqsT_W1eDq7uNkOA%40mail.gmail.com%3E&References=%3CCAG%3Dut6LGivacoj28LHfcViNhA238LfA0%3DmUqsT_W1eDq7uNkOA%40mail.gmail.com%3E>> 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 <mailto:pvanderveen@terraxml.com?Subject=Re%3A%20%5BXsltforms-support%5D%20Is%20XForms%20a%20failure%20to%20learn%20from%3F&In-Reply-To=%3CCAG%3Dut6LGivacoj28LHfcViNhA238LfA0%3DmUqsT_W1eDq7uNkOA%40mail.gmail.com%3E&References=%3CCAG%3Dut6LGivacoj28LHfcViNhA238LfA0%3DmUqsT_W1eDq7uNkOA%40mail.gmail.com%3E> >> > wrote: >> >>> FYI. AngularJS is a declarative framework as well – conceptually very >>> similar to XForms >>> >>> >>> >>> *From:* William Velasquez [mailto:wvelasquez@visiontecnologica.com <mailto:wvelasquez@visiontecnologica.com?Subject=Re%3A%20%5BXsltforms-support%5D%20Is%20XForms%20a%20failure%20to%20learn%20from%3F&In-Reply-To=%3CCAG%3Dut6LGivacoj28LHfcViNhA238LfA0%3DmUqsT_W1eDq7uNkOA%40mail.gmail.com%3E&References=%3CCAG%3Dut6LGivacoj28LHfcViNhA238LfA0%3DmUqsT_W1eDq7uNkOA%40mail.gmail.com%3E>] >>> *Sent:* Thursday, October 16, 2014 10:21 AM >>> *To:*ihe.onwuka@gmail.com <mailto:ihe.onwuka@gmail.com?Subject=Re%3A%20%5BXsltforms-support%5D%20Is%20XForms%20a%20failure%20to%20learn%20from%3F&In-Reply-To=%3CCAG%3Dut6LGivacoj28LHfcViNhA238LfA0%3DmUqsT_W1eDq7uNkOA%40mail.gmail.com%3E&References=%3CCAG%3Dut6LGivacoj28LHfcViNhA238LfA0%3DmUqsT_W1eDq7uNkOA%40mail.gmail.com%3E>; Manuel Lautenschlager >>> *Cc:* Paul Vanderveen;xsltforms-support@lists.sourceforge.net <mailto:xsltforms-support@lists.sourceforge.net?Subject=Re%3A%20%5BXsltforms-support%5D%20Is%20XForms%20a%20failure%20to%20learn%20from%3F&In-Reply-To=%3CCAG%3Dut6LGivacoj28LHfcViNhA238LfA0%3DmUqsT_W1eDq7uNkOA%40mail.gmail.com%3E&References=%3CCAG%3Dut6LGivacoj28LHfcViNhA238LfA0%3DmUqsT_W1eDq7uNkOA%40mail.gmail.com%3E>; Forms >>> WG;public-xformsusers@w3.org <mailto:public-xformsusers@w3.org?Subject=Re%3A%20%5BXsltforms-support%5D%20Is%20XForms%20a%20failure%20to%20learn%20from%3F&In-Reply-To=%3CCAG%3Dut6LGivacoj28LHfcViNhA238LfA0%3DmUqsT_W1eDq7uNkOA%40mail.gmail.com%3E&References=%3CCAG%3Dut6LGivacoj28LHfcViNhA238LfA0%3DmUqsT_W1eDq7uNkOA%40mail.gmail.com%3E> >>> *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 <mailto:ihe.onwuka@gmail.com?Subject=Re%3A%20%5BXsltforms-support%5D%20Is%20XForms%20a%20failure%20to%20learn%20from%3F&In-Reply-To=%3CCAG%3Dut6LGivacoj28LHfcViNhA238LfA0%3DmUqsT_W1eDq7uNkOA%40mail.gmail.com%3E&References=%3CCAG%3Dut6LGivacoj28LHfcViNhA238LfA0%3DmUqsT_W1eDq7uNkOA%40mail.gmail.com%3E> <ihe.onwuka@gmail.com <mailto:ihe.onwuka@gmail.com?Subject=Re%3A%20%5BXsltforms-support%5D%20Is%20XForms%20a%20failure%20to%20learn%20from%3F&In-Reply-To=%3CCAG%3Dut6LGivacoj28LHfcViNhA238LfA0%3DmUqsT_W1eDq7uNkOA%40mail.gmail.com%3E&References=%3CCAG%3Dut6LGivacoj28LHfcViNhA238LfA0%3DmUqsT_W1eDq7uNkOA%40mail.gmail.com%3E>>] >>> *Enviado el:* jueves, 16 de octubre de 2014 10:51 a. m. >>> *Para:* Manuel Lautenschlager >>> *CC:* Paul Vanderveen;xsltforms-support@lists.sourceforge.net <mailto:xsltforms-support@lists.sourceforge.net?Subject=Re%3A%20%5BXsltforms-support%5D%20Is%20XForms%20a%20failure%20to%20learn%20from%3F&In-Reply-To=%3CCAG%3Dut6LGivacoj28LHfcViNhA238LfA0%3DmUqsT_W1eDq7uNkOA%40mail.gmail.com%3E&References=%3CCAG%3Dut6LGivacoj28LHfcViNhA238LfA0%3DmUqsT_W1eDq7uNkOA%40mail.gmail.com%3E>; Forms >>> WG;public-xformsusers@w3.org <mailto:public-xformsusers@w3.org?Subject=Re%3A%20%5BXsltforms-support%5D%20Is%20XForms%20a%20failure%20to%20learn%20from%3F&In-Reply-To=%3CCAG%3Dut6LGivacoj28LHfcViNhA238LfA0%3DmUqsT_W1eDq7uNkOA%40mail.gmail.com%3E&References=%3CCAG%3Dut6LGivacoj28LHfcViNhA238LfA0%3DmUqsT_W1eDq7uNkOA%40mail.gmail.com%3E> >>> *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 <mailto:Manuel.Lautenschlager@ascio.com?Subject=Re%3A%20%5BXsltforms-support%5D%20Is%20XForms%20a%20failure%20to%20learn%20from%3F&In-Reply-To=%3CCAG%3Dut6LGivacoj28LHfcViNhA238LfA0%3DmUqsT_W1eDq7uNkOA%40mail.gmail.com%3E&References=%3CCAG%3Dut6LGivacoj28LHfcViNhA238LfA0%3DmUqsT_W1eDq7uNkOA%40mail.gmail.com%3E>> 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 <mailto:Xsltforms-support@lists.sourceforge.net?Subject=Re%3A%20%5BXsltforms-support%5D%20Is%20XForms%20a%20failure%20to%20learn%20from%3F&In-Reply-To=%3CCAG%3Dut6LGivacoj28LHfcViNhA238LfA0%3DmUqsT_W1eDq7uNkOA%40mail.gmail.com%3E&References=%3CCAG%3Dut6LGivacoj28LHfcViNhA238LfA0%3DmUqsT_W1eDq7uNkOA%40mail.gmail.com%3E> >>https://lists.sourceforge.net/lists/listinfo/xsltforms-support >> >> >
Received on Friday, 17 October 2014 07:04:23 UTC