xsltforms-support Mailing List for XSLTForms (Page 24)
Brought to you by:
alain-couthures
You can subscribe to this list here.
2009 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(6) |
Jun
(9) |
Jul
(16) |
Aug
(5) |
Sep
(43) |
Oct
(36) |
Nov
(58) |
Dec
(43) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2010 |
Jan
(79) |
Feb
(81) |
Mar
(107) |
Apr
(93) |
May
(85) |
Jun
(54) |
Jul
(64) |
Aug
(54) |
Sep
(45) |
Oct
(53) |
Nov
(34) |
Dec
(77) |
2011 |
Jan
(56) |
Feb
(53) |
Mar
(52) |
Apr
(66) |
May
(44) |
Jun
(16) |
Jul
(28) |
Aug
(5) |
Sep
(15) |
Oct
(21) |
Nov
(51) |
Dec
(46) |
2012 |
Jan
(16) |
Feb
(38) |
Mar
(47) |
Apr
(45) |
May
(41) |
Jun
(41) |
Jul
(72) |
Aug
(17) |
Sep
(10) |
Oct
(16) |
Nov
(29) |
Dec
(30) |
2013 |
Jan
(25) |
Feb
(13) |
Mar
(20) |
Apr
(25) |
May
(34) |
Jun
(8) |
Jul
(12) |
Aug
(9) |
Sep
(21) |
Oct
(19) |
Nov
(6) |
Dec
(2) |
2014 |
Jan
(14) |
Feb
(8) |
Mar
(7) |
Apr
(13) |
May
(33) |
Jun
(13) |
Jul
(6) |
Aug
(5) |
Sep
(5) |
Oct
(34) |
Nov
(7) |
Dec
|
2015 |
Jan
(1) |
Feb
(6) |
Mar
(17) |
Apr
(12) |
May
(10) |
Jun
(18) |
Jul
(31) |
Aug
(9) |
Sep
(3) |
Oct
(6) |
Nov
(19) |
Dec
(1) |
2016 |
Jan
(18) |
Feb
(4) |
Mar
(13) |
Apr
(19) |
May
|
Jun
(17) |
Jul
(7) |
Aug
|
Sep
(3) |
Oct
(6) |
Nov
(3) |
Dec
|
2017 |
Jan
(5) |
Feb
(17) |
Mar
(4) |
Apr
(8) |
May
(3) |
Jun
|
Jul
(8) |
Aug
(2) |
Sep
|
Oct
(5) |
Nov
(6) |
Dec
(4) |
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(6) |
Nov
|
Dec
(1) |
2019 |
Jan
|
Feb
|
Mar
(4) |
Apr
(2) |
May
(4) |
Jun
|
Jul
|
Aug
(2) |
Sep
(7) |
Oct
|
Nov
|
Dec
|
2020 |
Jan
(13) |
Feb
(17) |
Mar
(8) |
Apr
(11) |
May
(15) |
Jun
(11) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(6) |
2021 |
Jan
(9) |
Feb
(26) |
Mar
(17) |
Apr
|
May
(7) |
Jun
(18) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(10) |
2022 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
(2) |
Sep
(3) |
Oct
(2) |
Nov
(10) |
Dec
(1) |
2023 |
Jan
(10) |
Feb
|
Mar
(7) |
Apr
(8) |
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
(8) |
Oct
(11) |
Nov
(8) |
Dec
(5) |
2024 |
Jan
(7) |
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2025 |
Jan
(4) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Benoit V. <bvi...@la...> - 2014-11-08 11:10:14
|
Hi Alain, It would be very useful for our application to have the <xf:select1 selection="open" /> implemented in XSLTForms. I searched on the web and found that, now, with HTML 5 it's very easy to have a combobox without coding anything in javascript : example : <input type="text" list="browsers" /> <datalist id="browsers" > <option> Google </option> <option> IE9 </option> </datalist> I think it could be possible to implement <xf:select1 selection="open" /> in XSLTForms by merging the existing code of xf:input (for the field) and the xf:select1 (for the options list). I tried some quick and dirty tests and it seems to work for modern browsers. I try to generate the HTML with a template like this : <xsl:template xmlns:xsl="http://www.w3.org/1999/XSL/Transform" match="xforms:select1[@selection='open']" priority="3"> <xsl:param name="appearance" select="false()"/> <xsl:param name="parentworkid"/> <xsl:param name="workid" select="concat(position(),'_',$parentworkid)"/> <xsl:call-template name="field"> <xsl:with-param name="workid" select="$workid"/> <xsl:with-param name="appearance" select="$appearance"/> <xsl:with-param name="body"> <input type="text" list="datalist-{$workid}"> <xsl:call-template name="comun"/> </input> <datalist id="datalist-{$workid}"> <xsl:apply-templates select="node()" mode="item"> <xsl:with-param name="parentworkid" select="$workid"/> </xsl:apply-templates> </datalist> </xsl:with-param> </xsl:call-template> </xsl:template> but I have not enough skills to modify the javascript generation code. I'm stuck ! Do you think that it would be possible to have this feature in XSLTForms (at least for HTML 5 browser)? Thank you for your help. Benoit |
From: William V. <wve...@vi...> - 2014-10-22 16:33:14
|
Thanks Alain, Reading your response, now I think subforms is what I need. My scenario is a something like a Single Page Application, where the user can select a form template (from a list in the left of the page) and then view the form (in the right pane). Each form is a different XForms, and must be shown without reloading the page. I’ll try with subforms and share me results here. - Bill De: ala...@ag... [mailto:ala...@ag...] Enviado el: martes, 21 de octubre de 2014 3:33 p. m. Para: xsl...@li...; William Velasquez Asunto: Re: [Xsltforms-support] Injecting XSLTForms Hello William, The subform mechanism is performing something very similar and, for subforms, the XSLT stylesheet can still be applied client-side. I also prototyped, some time ago, a way to embed XForms tags within a page being fully assembled by the server. You can find the corresponding Javascript instructions at the very end of the xsltforms.js file. The trick is to add a script element with a type attribute being "text/xforms" (probably not the best value for that purpose, just a prototype...). I have fixed some issues to be in a commit to come and it sounds like that : <html> <head> <title>Hello World in XForms</title> </head> <body> <p>Type your first name in the input box. <br/> If you are running XForms, the output should be displayed in the output area.</p> <script type="text/javascript" src="/xsltforms/trunk/src/xsltforms.js"></script> <script type="text/xforms"> <xf:model xmlns:xf="http://www.w3.org/2002/xforms"> <xf:instance> <data xmlns=""> <PersonGivenName/> </data> </xf:instance> </xf:model> <xf:input xmlns:xf="http://www.w3.org/2002/xforms" ref="PersonGivenName" incremental="true"> <xf:label>Please enter your first name: </xf:label> </xf:input> <br /> <xf:output xmlns:xf="http://www.w3.org/2002/xforms" value="concat('Hello ', PersonGivenName, '. We hope you like XForms!')"> <xf:label>Output: </xf:label> </xf:output> </script> </body> </html> As you can see, this is not exactly what you are looking for. You should have in mind that there are always two parts resulting from the XSLT transformation: generated Javascript instructions and generated HTML tags. In subform mechanism and, similarly, in the prototype, the result of the transformation is sliced to extract those two parts and, then, they are integrated within the current page. For a server process, it is not well optimized to have to perform this, each and every time. A solution would be to generate everything with the XSLT transformation and a parameter for this. It might be a document fragment to be inserted or, maybe better, a unique script element to be executed for creating all the form (in this case, the src attribute could even be useful for a dynamic insertion at client side!). What do you think? --Alain Le 20 octobre 2014 à 23:30, William Velasquez <wve...@vi...<mailto:wve...@vi...>> a écrit : Hi folks! Has anybody successfully injected the result of the XSLTForms transformation into an HTML page? If the answer is yes, where is the trick? Is necessary to call some javascript initialization? I’m doing it via InjectBoundHtml method in Google Polymer, and the DOM is loaded, but the form doesn’t run. Thanks for your ideas, William David Velásquez Director de Investigación y Desarrollo Visión Tecnológica S.A.S. www.visiontecnologica.com<http://www.visiontecnologica.com> Tel (57 4) 444 7292 Movil (57) 311 709 8421 Follow me @williamda ------------------------------------------------------------------------------ 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 Xsl...@li...<mailto:Xsl...@li...> https://lists.sourceforge.net/lists/listinfo/xsltforms-support |
From: <ala...@ag...> - 2014-10-21 20:32:59
|
Hello William, The subform mechanism is performing something very similar and, for subforms, the XSLT stylesheet can still be applied client-side. I also prototyped, some time ago, a way to embed XForms tags within a page being fully assembled by the server. You can find the corresponding Javascript instructions at the very end of the xsltforms.js file. The trick is to add a script element with a type attribute being "text/xforms" (probably not the best value for that purpose, just a prototype...). I have fixed some issues to be in a commit to come and it sounds like that : <html> <head> <title>Hello World in XForms</title> </head> <body> <p>Type your first name in the input box. <br/> If you are running XForms, the output should be displayed in the output area.</p> <script type="text/javascript" src="/xsltforms/trunk/src/xsltforms.js"></script> <script type="text/xforms"> <xf:model xmlns:xf="http://www.w3.org/2002/xforms"> <xf:instance> <data xmlns=""> <PersonGivenName/> </data> </xf:instance> </xf:model> <xf:input xmlns:xf="http://www.w3.org/2002/xforms" ref="PersonGivenName" incremental="true"> <xf:label>Please enter your first name: </xf:label> </xf:input> <br /> <xf:output xmlns:xf="http://www.w3.org/2002/xforms" value="concat('Hello ', PersonGivenName, '. We hope you like XForms!')"> <xf:label>Output: </xf:label> </xf:output> </script> </body> </html> As you can see, this is not exactly what you are looking for. You should have in mind that there are always two parts resulting from the XSLT transformation: generated Javascript instructions and generated HTML tags. In subform mechanism and, similarly, in the prototype, the result of the transformation is sliced to extract those two parts and, then, they are integrated within the current page. For a server process, it is not well optimized to have to perform this, each and every time. A solution would be to generate everything with the XSLT transformation and a parameter for this. It might be a document fragment to be inserted or, maybe better, a unique script element to be executed for creating all the form (in this case, the src attribute could even be useful for a dynamic insertion at client side!). What do you think? --Alain > Le 20 octobre 2014 à 23:30, William Velasquez > <wve...@vi...> a écrit : > > > Hi folks! > > > > Has anybody successfully injected the result of the XSLTForms transformation > into an HTML page? > > > > If the answer is yes, where is the trick? Is necessary to call some > javascript initialization? > > > > I’m doing it via InjectBoundHtml method in Google Polymer, and the DOM is > loaded, but the form doesn’t run. > > > > Thanks for your ideas, > > > > > > William David Velásquez > > Director de Investigación y Desarrollo > > Visión Tecnológica S.A.S. > > www.visiontecnologica.com <http://www.visiontecnologica.com> > > Tel (57 4) 444 7292 > > Movil (57) 311 709 8421 > > Follow me @williamda > > > > ------------------------------------------------------------------------------ > 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 > Xsl...@li... > https://lists.sourceforge.net/lists/listinfo/xsltforms-support > |
From: marcelo a. <cma...@gm...> - 2014-10-21 12:34:53
|
Hi William, what I do is to use XMLStartlet, a little-very-very-useful utility, to "compile" my xforms into html... That is what is served and used. I've made a little Makefile that keeps the things more organized but basically what I do is: xml tr -E xforms/myxforms.xform > html/myxforms_now_as_html.html in this case the xsltforms.xsl lives in its own directory xsltforms/ and is referenced by the xform in the usual way... <?xml-stylesheet href="../xsltforms/xsltforms.xsl" type="text/xsl"?> I hope this help cheers marcelo On Mon, Oct 20, 2014 at 6:30 PM, William Velasquez < wve...@vi...> wrote: > Hi folks! > > > > Has anybody successfully injected the result of the XSLTForms > transformation into an HTML page? > > > > If the answer is yes, where is the trick? Is necessary to call some > javascript initialization? > > > > I’m doing it via InjectBoundHtml method in Google Polymer, and the DOM is > loaded, but the form doesn’t run. > > > > Thanks for your ideas, > > > > > > William David Velásquez > > Director de Investigación y Desarrollo > > Visión Tecnológica S.A.S. > > www.visiontecnologica.com > > Tel (57 4) 444 7292 > > Movil (57) 311 709 8421 > > Follow me @williamda > > > > > ------------------------------------------------------------------------------ > 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 > Xsl...@li... > https://lists.sourceforge.net/lists/listinfo/xsltforms-support > > -- +569 7 887 2890 +562 2 378 1264 +562 2 227 3403 |
From: William V. <wve...@vi...> - 2014-10-20 22:04:39
|
Hi folks! Has anybody successfully injected the result of the XSLTForms transformation into an HTML page? If the answer is yes, where is the trick? Is necessary to call some javascript initialization? I'm doing it via InjectBoundHtml method in Google Polymer, and the DOM is loaded, but the form doesn't run. Thanks for your ideas, William David Velásquez Director de Investigación y Desarrollo Visión Tecnológica S.A.S. www.visiontecnologica.com<http://www.visiontecnologica.com> Tel (57 4) 444 7292 Movil (57) 311 709 8421 Follow me @williamda |
From: Manuel L. <Man...@as...> - 2014-10-20 10:26:01
|
Hi, Maybe being declarative is an issue. Maybe marketing is an issue. https://angularjs.org/ vs. http://www.w3.org/TR/xforms11/ I think the key would be to integrate better into the “normal” world, outside of the XML-Community: · Have PHP modules, not only this: http://php.net/manual/en/features.xforms.php · Have a HTML5 translation of XForms for you can work with a normal editor. (<div data-instance=”myData”/>) · Create XForms modules for several Platforms (e.g. Wordpress, Joomla, Drupal) · Publish and promote these modules, should have a clear advantage to existing solutions. I like the combination eXist-DB, Schema, XSLT, XForms. But to have success, we need to integrate into tools that a are less advanced. Separate XForms from the XML community, and introduce it to the PHP-Mysql community. I don’t like this, but I am very sure it is necessary to make the standard popular. When it has arrived in the PHP world it’s a standard, so sad this may sound ☺ Manuel From: Paul Vanderveen [mailto:pva...@te...] Sent: Donnerstag, 16. Oktober 2014 20:21 To: William Velasquez; ihe...@gm...; Manuel Lautenschlager Cc: xsl...@li...; Forms WG; pub...@w3... Subject: RE: [Xsltforms-support] Is XForms a failure to learn from? FYI. AngularJS is a declarative framework as well – conceptually very similar to XForms From: William Velasquez [mailto:wve...@vi...] Sent: Thursday, October 16, 2014 10:21 AM To: ihe...@gm...<mailto:ihe...@gm...>; Manuel Lautenschlager Cc: Paul Vanderveen; xsl...@li...<mailto:xsl...@li...>; Forms WG; pub...@w3...<mailto:pub...@w3...> 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...@gm...] Enviado el: jueves, 16 de octubre de 2014 10:51 a. m. Para: Manuel Lautenschlager CC: Paul Vanderveen; xsl...@li...<mailto:xsl...@li...>; Forms WG; pub...@w3...<mailto:pub...@w3...> Asunto: Re: [Xsltforms-support] Is XForms a failure to learn from? On Thu, Oct 16, 2014 at 3:46 PM, Manuel Lautenschlager <Man...@as...<mailto:Man...@as...>> 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. |
From: Stephen C. <ste...@gm...> - 2014-10-20 00:18:32
|
On Mon, Oct 20, 2014 at 4:00 AM, Jarosław Kowalewski < jar...@st...> 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 <ste...@gm...>: > > 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 > |
From: Jarosław K. <jar...@st...> - 2014-10-19 17:01:24
|
Steve, I cannot agree with you in some points. 2014-10-17 23:33 GMT+02:00 Stephen Cameron <ste...@gm...>: > 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. 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. 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! 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. In xforms all I need is good knowladge of xpath. 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. 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. Jarek |
From: Stephen C. <ste...@gm...> - 2014-10-17 21:33:53
|
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...@gm...> wrote: > > > On Fri, Oct 17, 2014 at 1:00 AM, Stephen Cameron < > ste...@gm...> 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. > > > > |
From: Ihe O. <ihe...@gm...> - 2014-10-17 14:44:33
|
On Fri, Oct 17, 2014 at 1:00 AM, Stephen Cameron <ste...@gm... > 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. |
From: michael odling-s. <mic...@xm...> - 2014-10-17 13:40:17
|
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 <ste...@gm...> 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 < > ste...@gm...> 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...@gm...> 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 < >>> pva...@te...> wrote: >>> >>>> FYI. AngularJS is a declarative framework as well – conceptually >>>> very similar to XForms >>>> >>>> >>>> >>>> *From:* William Velasquez [mailto:wve...@vi...] >>>> *Sent:* Thursday, October 16, 2014 10:21 AM >>>> *To:* ihe...@gm...; Manuel Lautenschlager >>>> *Cc:* Paul Vanderveen; xsl...@li...; Forms >>>> WG; pub...@w3... >>>> *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...@gm... <ihe...@gm...>] >>>> *Enviado el:* jueves, 16 de octubre de 2014 10:51 a. m. >>>> *Para:* Manuel Lautenschlager >>>> *CC:* Paul Vanderveen; xsl...@li...; Forms >>>> WG; pub...@w3... >>>> *Asunto:* Re: [Xsltforms-support] Is XForms a failure to learn from? >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Thu, Oct 16, 2014 at 3:46 PM, Manuel Lautenschlager < >>>> Man...@as...> 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 >>> Xsl...@li... >>> https://lists.sourceforge.net/lists/listinfo/xsltforms-support >>> >>> >> > -- -- Michael Odling-Smee | mi...@xm... | 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 |
From: Mark L. <tin...@gm...> - 2014-10-17 12:00:32
|
Hi, It’s been interesting reading the various options over the last few days and mirrors what I’ve heard in XML conferences over the last few years (along with much chest beating over JSON). My two cents, for what it’s worth, is that there are two very different needs/tools in play. The first is very much document-based, and here where I am in the public sector is a good example. There are large numbers of, often very complex, forms that used to be paper: are now web-based but still essentially *transactional*. Fill, validate, search, retrieve, modify, print etc. Fill out an application for a drivers licence, a passport or an income tax form and you’re looking into that world - and it’s not going away any time soon. XForms is an efficient, cost-effective solution here, and one of the reasons we use it pretty much exclusively, in the xsltforms variant, for our interfaces. The backend data is XML for exactly the same reasons; it supports the document paradigm the best. The other world is a Stephen describes it; the browser as application container, perhaps using our old friend Angular, with a steady stream of bi-directional data to/from the backend via JSON (Node.js+MongoDb perhaps). It’s a perfect fit for modern browser ‘apps’, and wildly, feverishly popular. I do worry that no matter how fast my browser, a bigger, fatter JS ‘framework’ will appear with a clang, promising even more illusive ‘productivity’ to the hard-pressed web development team. To be honest, I don’t think there’s a conversation to be had between the two. XForms is a W3C standard, it moves slowly, but it’s consistent and reliable. The JS/App world is a roiling Darwinian sea of competitive and incompatible libraries. The world of the document is a niche market, unremarked and likely to stay that way, to the rest of the web-site creating portion of humanity. Does it matter if it stays a niche? I don’t think so as long as there is a healthy mix of commercial and open-source solutions available and it remains a good way of solving the problem. It’s going to be more of an issue in the future if a lack of X-skills, lead to good solutions being replaced with just adequate ones. Rgds, Mark Lawson Senior Technical Architect Staffordshire and West Midlands Community Rehabilitation Company [sent from home email] On 17 Oct 2014, at 01:00, Stephen Cameron <ste...@gm...> 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...@gm...> 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 <pva...@te...> wrote: > FYI. AngularJS is a declarative framework as well – conceptually very similar to XForms > > > > From: William Velasquez [mailto:wve...@vi...] > Sent: Thursday, October 16, 2014 10:21 AM > To: ihe...@gm...; Manuel Lautenschlager > Cc: Paul Vanderveen; xsl...@li...; Forms WG; pub...@w3... > 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...@gm...] > Enviado el: jueves, 16 de octubre de 2014 10:51 a. m. > Para: Manuel Lautenschlager > CC: Paul Vanderveen; xsl...@li...; Forms WG; pub...@w3... > Asunto: Re: [Xsltforms-support] Is XForms a failure to learn from? > > > > > > > > On Thu, Oct 16, 2014 at 3:46 PM, Manuel Lautenschlager <Man...@as...> 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 > Xsl...@li... > https://lists.sourceforge.net/lists/listinfo/xsltforms-support > > |
From: Stephen C. <ste...@gm...> - 2014-10-17 11:38:50
|
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 < ste...@gm...> 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...@gm...> 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 < >> pva...@te...> wrote: >> >>> FYI. AngularJS is a declarative framework as well – conceptually very >>> similar to XForms >>> >>> >>> >>> *From:* William Velasquez [mailto:wve...@vi...] >>> *Sent:* Thursday, October 16, 2014 10:21 AM >>> *To:* ihe...@gm...; Manuel Lautenschlager >>> *Cc:* Paul Vanderveen; xsl...@li...; Forms >>> WG; pub...@w3... >>> *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...@gm... <ihe...@gm...>] >>> *Enviado el:* jueves, 16 de octubre de 2014 10:51 a. m. >>> *Para:* Manuel Lautenschlager >>> *CC:* Paul Vanderveen; xsl...@li...; Forms >>> WG; pub...@w3... >>> *Asunto:* Re: [Xsltforms-support] Is XForms a failure to learn from? >>> >>> >>> >>> >>> >>> >>> >>> On Thu, Oct 16, 2014 at 3:46 PM, Manuel Lautenschlager < >>> Man...@as...> 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 >> Xsl...@li... >> https://lists.sourceforge.net/lists/listinfo/xsltforms-support >> >> > |
From: Stephen C. <ste...@gm...> - 2014-10-17 00:00:35
|
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...@gm...> 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 <pva...@te... > > wrote: > >> FYI. AngularJS is a declarative framework as well – conceptually very >> similar to XForms >> >> >> >> *From:* William Velasquez [mailto:wve...@vi...] >> *Sent:* Thursday, October 16, 2014 10:21 AM >> *To:* ihe...@gm...; Manuel Lautenschlager >> *Cc:* Paul Vanderveen; xsl...@li...; Forms >> WG; pub...@w3... >> *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...@gm... <ihe...@gm...>] >> *Enviado el:* jueves, 16 de octubre de 2014 10:51 a. m. >> *Para:* Manuel Lautenschlager >> *CC:* Paul Vanderveen; xsl...@li...; Forms >> WG; pub...@w3... >> *Asunto:* Re: [Xsltforms-support] Is XForms a failure to learn from? >> >> >> >> >> >> >> >> On Thu, Oct 16, 2014 at 3:46 PM, Manuel Lautenschlager < >> Man...@as...> 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 > Xsl...@li... > https://lists.sourceforge.net/lists/listinfo/xsltforms-support > > |
From: Ihe O. <ihe...@gm...> - 2014-10-16 19:56:05
|
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 <pva...@te...> wrote: > FYI. AngularJS is a declarative framework as well – conceptually very > similar to XForms > > > > *From:* William Velasquez [mailto:wve...@vi...] > *Sent:* Thursday, October 16, 2014 10:21 AM > *To:* ihe...@gm...; Manuel Lautenschlager > *Cc:* Paul Vanderveen; xsl...@li...; Forms WG; > pub...@w3... > *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...@gm... <ihe...@gm...>] > *Enviado el:* jueves, 16 de octubre de 2014 10:51 a. m. > *Para:* Manuel Lautenschlager > *CC:* Paul Vanderveen; xsl...@li...; Forms WG; > pub...@w3... > *Asunto:* Re: [Xsltforms-support] Is XForms a failure to learn from? > > > > > > > > On Thu, Oct 16, 2014 at 3:46 PM, Manuel Lautenschlager < > Man...@as...> 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. > > > > > > > |
From: Paul V. <pva...@te...> - 2014-10-16 18:54:51
|
FYI. AngularJS is a declarative framework as well – conceptually very similar to XForms From: William Velasquez [mailto:wve...@vi...] Sent: Thursday, October 16, 2014 10:21 AM To: ihe...@gm...; Manuel Lautenschlager Cc: Paul Vanderveen; xsl...@li...; Forms WG; pub...@w3... 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...@gm...] Enviado el: jueves, 16 de octubre de 2014 10:51 a. m. Para: Manuel Lautenschlager CC: Paul Vanderveen; xsl...@li...<mailto:xsl...@li...>; Forms WG; pub...@w3...<mailto:pub...@w3...> Asunto: Re: [Xsltforms-support] Is XForms a failure to learn from? On Thu, Oct 16, 2014 at 3:46 PM, Manuel Lautenschlager <Man...@as...<mailto:Man...@as...>> 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. |
From: William V. <wve...@vi...> - 2014-10-16 16:21:26
|
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...@gm...] Enviado el: jueves, 16 de octubre de 2014 10:51 a. m. Para: Manuel Lautenschlager CC: Paul Vanderveen; xsl...@li...; Forms WG; pub...@w3... Asunto: Re: [Xsltforms-support] Is XForms a failure to learn from? On Thu, Oct 16, 2014 at 3:46 PM, Manuel Lautenschlager <Man...@as...<mailto:Man...@as...>> 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. |
From: Ihe O. <ihe...@gm...> - 2014-10-16 15:51:20
|
On Thu, Oct 16, 2014 at 3:46 PM, Manuel Lautenschlager < Man...@as...> 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. > > |
From: Manuel L. <Man...@as...> - 2014-10-16 14:58:41
|
What is lightweight? For me lightweight is: Parsing takes only little resources. Implementation is easy with a few lines of code. Only necessary functionality. Not lightweight is: Very complex framework that tries to cover everything. I’m sure XML needs a few more lines to implement than JSON. 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) 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. 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 ☺ From: Ihe Onwuka [mailto:ihe...@gm...] Sent: Mittwoch, 15. Oktober 2014 21:48 To: Paul Vanderveen Cc: Alain Couthures; Forms WG; pub...@w3...; xsl...@li... Subject: Re: [Xsltforms-support] Is XForms a failure to learn from? On Wed, Oct 15, 2014 at 7:23 PM, Paul Vanderveen <pva...@te...<mailto:pva...@te...>> wrote: Interesting thread We have integrated XForms into our product, and I would never say that XForms is a failure. I do, however, think that for largely non-technical reasons the world has decided to go in other directions. The work Alain’s done with XSLTForms is phenomenal, but XML in general is being hit hard in favor of lighter weight protocols. Except that they are generally not lighter weight but people are being taken in by the myth. I think XSLT is safe in that there is no real competitor for transforming XML documents. XQuery is questionable as a transformation technology (IMHO), but it is still the best way to query an XML database full of XML content. But even large XML database proponents like MarkLogic are supporting JSON as well as XML these days. Probably because they have smarter people working for them than the NOSql vendors who pretend that XML doesn't exist. At TerraXML we have recently decided to adopt AngularJS for our new front end work, and the more I learn about it the more I see just how many similarities it has with XForms. The model may be JSON instead of XML, but it is uncanny how it almost has a feature to feature match with XForms. Even some of the struggles we’ve had with XForms also come across when building an AngularJS forms (I call it trial and error programming). XForms was on the right track, it just didn’t get critical mass. It needed somebody like Google to jump behind it and that didn’t happen. They jumped behind AngularJS instead. I don’t know what the future is for XForms, but our current plan is to support both XForms and HTML5/AngularJS for a time, but we will start migrate over to doing new forms using AngularJS. The mass have repeatedly proved their ability to congregate around and prop up bad ideas. JSON in a form... that somebody made it work doesn't mean that it's a good idea. |
From: Ihe O. <ihe...@gm...> - 2014-10-15 19:48:22
|
On Wed, Oct 15, 2014 at 7:23 PM, Paul Vanderveen <pva...@te...> wrote: > Interesting thread > > > > We have integrated XForms into our product, and I would never say that > XForms is a failure. I do, however, think that for largely non-technical > reasons the world has decided to go in other directions. The work Alain’s > done with XSLTForms is phenomenal, but XML in general is being hit hard in > favor of lighter weight protocols. > Except that they are generally not lighter weight but people are being taken in by the myth. > I think XSLT is safe in that there is no real competitor for transforming > XML documents. XQuery is questionable as a transformation technology > (IMHO), but it is still the best way to query an XML database full of XML > content. But even large XML database proponents like MarkLogic are > supporting JSON as well as XML these days. > > > Probably because they have smarter people working for them than the NOSql vendors who pretend that XML doesn't exist. > At TerraXML we have recently decided to adopt AngularJS for our new > front end work, and the more I learn about it the more I see just how many > similarities it has with XForms. The model may be JSON instead of XML, > but it is uncanny how it almost has a feature to feature match with > XForms. Even some of the struggles we’ve had with XForms also come across > when building an AngularJS forms (I call it trial and error > programming). XForms was on the right track, it just didn’t get critical > mass. It needed somebody like Google to jump behind it and that didn’t > happen. They jumped behind AngularJS instead. I don’t know what the > future is for XForms, but our current plan is to support both XForms and > HTML5/AngularJS for a time, but we will start migrate over to doing new > forms using AngularJS. > > > The mass have repeatedly proved their ability to congregate around and prop up bad ideas. JSON in a form... that somebody made it work doesn't mean that it's a good idea. |
From: William V. <wve...@vi...> - 2014-10-15 19:18:48
|
The problem with de facto is that they get replaced as fast as they become popular. Now Google is working on polymer and surely all that angularjs work will be thrown to the trash can soon. Perdon por haber sido escueto, pero estoy escribiendo desde mi teléfono móvil. El oct 15, 2014 1:39 PM, Paul Vanderveen <pva...@te...> escribió: Interesting thread We have integrated XForms into our product, and I would never say that XForms is a failure. I do, however, think that for largely non-technical reasons the world has decided to go in other directions. The work Alain's done with XSLTForms is phenomenal, but XML in general is being hit hard in favor of lighter weight protocols. I think XSLT is safe in that there is no real competitor for transforming XML documents. XQuery is questionable as a transformation technology (IMHO), but it is still the best way to query an XML database full of XML content. But even large XML database proponents like MarkLogic are supporting JSON as well as XML these days. At TerraXML we have recently decided to adopt AngularJS for our new front end work, and the more I learn about it the more I see just how many similarities it has with XForms. The model may be JSON instead of XML, but it is uncanny how it almost has a feature to feature match with XForms. Even some of the struggles we've had with XForms also come across when building an AngularJS forms (I call it trial and error programming). XForms was on the right track, it just didn't get critical mass. It needed somebody like Google to jump behind it and that didn't happen. They jumped behind AngularJS instead. I don't know what the future is for XForms, but our current plan is to support both XForms and HTML5/AngularJS for a time, but we will start migrate over to doing new forms using AngularJS. Paul Vanderveen, Product Architect TerraXML, Inc. |
From: Paul V. <pva...@te...> - 2014-10-15 18:39:00
|
Interesting thread We have integrated XForms into our product, and I would never say that XForms is a failure. I do, however, think that for largely non-technical reasons the world has decided to go in other directions. The work Alain's done with XSLTForms is phenomenal, but XML in general is being hit hard in favor of lighter weight protocols. I think XSLT is safe in that there is no real competitor for transforming XML documents. XQuery is questionable as a transformation technology (IMHO), but it is still the best way to query an XML database full of XML content. But even large XML database proponents like MarkLogic are supporting JSON as well as XML these days. At TerraXML we have recently decided to adopt AngularJS for our new front end work, and the more I learn about it the more I see just how many similarities it has with XForms. The model may be JSON instead of XML, but it is uncanny how it almost has a feature to feature match with XForms. Even some of the struggles we've had with XForms also come across when building an AngularJS forms (I call it trial and error programming). XForms was on the right track, it just didn't get critical mass. It needed somebody like Google to jump behind it and that didn't happen. They jumped behind AngularJS instead. I don't know what the future is for XForms, but our current plan is to support both XForms and HTML5/AngularJS for a time, but we will start migrate over to doing new forms using AngularJS. Paul Vanderveen, Product Architect TerraXML, Inc. |
From: Stephen C. <ste...@gm...> - 2014-10-14 22:42:55
|
A very good summary Bill. There is no restriction on people building on the XForms recommendation. The only danger in that is it will be hard to standardise it in future once people have added their own approaches to solving the same issue. But this has been happening with XForms for a while now, I am thinking of Orbeon mostly, no criticism meant. But there does seem to be a middle ground, which is to make a parallel HTML5/Javascript version of XForms that defines a set of attributes (starting with xf- perhaps) and allows Javascript routines to be included into the processing events more easily. This is moving away from the declarative markup approach of XForms, but could be a bridge to those interested in making use of the XForms goodness but not wanting to write that horrible XML stuff. It could still feed back into a purely declarative W3C standard. The use of XPath is what gives XForms much of its power and that is as easily used in binds in this parrallel version as a markup version I suspect. It would be trivial to build it onto xsltforms.js I suspect. The schema integration aspect that you mention Bill is very important, I agree there is a problem (as mentioned already) with XForms in that you can write XPaths that contain element name errors and wonder why you don't see what you expect to see in the form. This could be prevented with good schema validation built into the form. XSLTForms allow schema validation at a simple level, but it doesn't check XPaths for invalid names. In terms of maintenance it not as good as having schema aware XForms editors, but is almost as good. Also, this could make XForms a true MVC platform, in that the components with their own Javascript controllers become possible. If anyone is interested to explore this I'd be keen, but the horse has bolted to a large extent (in the form of AngularJS). I have and do wonder if there is be a data focused market niche that is still there to be claimed. Steve On Wed, Oct 15, 2014 at 2:02 AM, William Velasquez < wve...@vi...> wrote: > I´d like to know the w3C definition of success: > - If success is: "making an standard globally accepted and implemented > like HTTP+HTML" everything after it has been a failure, even the last > version of HTML, because not all browser vendors obey w3c (ask WHATWG what > they think). > - If success is: "achieving initial goals", many w3c projects fits that > definition, but surely XForms don´t, because native browser support. > - But if success is: "Creating an useful specification that is implemented > in real world and offer benefits to their users", all of XSLTForms and > BetterForms users have to qualify XForms as a success. > - And even more, if success is "creating an standard that lasts for years > and shows the right path, even when others miss it" XForms is a total > success. The recent - and very popular - movement of "Web Components" is > re-launching the ideas behind XForms, and even XForms could be considered > the first "web components" framework. > > Now, if w3c drops XForms development (for being unsuccessful) and release > it to the community, that could benefit XForms community, and long awaited > features could see the light faster, like: > - Reutilization (like Jaroslaw told us). > - Integration with schema validation engines (not only XSD, but Relax-NG, > Schematron or Explamplotron). > - No-namespace version of XForms > > Just to name a few of many that this community could be waiting for. > > Cheers, > > - Bill > > > > > -----Mensaje original----- > De: Jarosław Kowalewski [mailto:jar...@st...] > Enviado el: martes, 14 de octubre de 2014 8:50 a. m. > Para: Stephen Cameron > CC: Forms WG; xsl...@li...; > pub...@w3... > Asunto: Re: [Xsltforms-support] Is XForms a failure to learn from? > > All, > I active use xforms technology since 2008 and I want to share my point of > view. > > Xforms form for me is very very powerful technology for building big forms > with complicated logic. Please refer e.g. to EU Commission e-forms like > http://erasmus-plus.ro/erasmus-plus-eforms-application-guide/. > > Similar forms I and my coullegues implemented in xforms. And that's work > currently only in FF3.6 with xforms plugin:/ > > If you want to see how it works feel free to create account and after > login choose e.g. "The scolarship and training found" and then > "Application forms". https://online.frse.org.pl. > > > For what this introduction? > > As I was started to develope my first xforms I was suprised how easy it > is. But it was only first impression, because I met a lot of problems and > low productivity in developing, chaning and debuging: > > 1. you have to write xml (main instance, origin instance, other instances > if necessary), xsd, xforms (and as in my case latex print tamplate too) > file separatly. > 2. if you want change structure of xml (e.g. rename some nodes) you must > change manually xsd, xfoms and latex file too. You must update all binds > and fields 3. You cannot reuse fragments of this files in another context > becouse you must do the same as in point 2. > 4. If you want to add some specific constuction e.g. repeat list that show > only a few fileds on the list e.g. name and surname but you want add > subform to edit more details each time you must write it again and again. > Please imagine that in one form you have 20-30 of such constructions. > 5. and a lot of other problems > > All this above is time consuming and causes many errors. > > So taking into account our problems we developed own framework that solved > almost all problems: reusable code, easy in maintain, etc., > > If anyone is intrested in details I can prepare some complex examples. > In attachment I added some code that is transformed via xslt to xforms, > xml, xsd and latex template. The main features are: xpath independent > bindings, field definition contains control type, label, nodename, xsd > type, size in grid layout online and independent size in grid layout in > latex, bind element, hint element. In last five years we build based on > that framework more than 2000 diffrent forms. > > I think about publishing it on SF. > > > Stephen Cameron said about AngularJS. I have attempted to implement xforms > in AngularJS becouse of similarities. But AngularJS forms are quite poor in > data binding. As I know exist only simple libraries that implement jsonpath > (https://code.google.com/p/json-path/) < xpath 1.0. > Xpath is the best and easiest way to go through data tree. > > > > Summarizing: > Xforms is currently the best specification for big forms, but difficult to > maintain. Xfomrs is a bed solution for small simple forms. Better use pure > js or AnlugarJS. > > All this solutions according to me need framework and xforms needs client > side implementation! The one last but promissing is XSLTForms. > > Regards > Jaroslaw Kowalewski > |
From: William V. <wve...@vi...> - 2014-10-14 15:18:56
|
I´d like to know the w3C definition of success: - If success is: "making an standard globally accepted and implemented like HTTP+HTML" everything after it has been a failure, even the last version of HTML, because not all browser vendors obey w3c (ask WHATWG what they think). - If success is: "achieving initial goals", many w3c projects fits that definition, but surely XForms don´t, because native browser support. - But if success is: "Creating an useful specification that is implemented in real world and offer benefits to their users", all of XSLTForms and BetterForms users have to qualify XForms as a success. - And even more, if success is "creating an standard that lasts for years and shows the right path, even when others miss it" XForms is a total success. The recent - and very popular - movement of "Web Components" is re-launching the ideas behind XForms, and even XForms could be considered the first "web components" framework. Now, if w3c drops XForms development (for being unsuccessful) and release it to the community, that could benefit XForms community, and long awaited features could see the light faster, like: - Reutilization (like Jaroslaw told us). - Integration with schema validation engines (not only XSD, but Relax-NG, Schematron or Explamplotron). - No-namespace version of XForms Just to name a few of many that this community could be waiting for. Cheers, - Bill -----Mensaje original----- De: Jarosław Kowalewski [mailto:jar...@st...] Enviado el: martes, 14 de octubre de 2014 8:50 a. m. Para: Stephen Cameron CC: Forms WG; xsl...@li...; pub...@w3... Asunto: Re: [Xsltforms-support] Is XForms a failure to learn from? All, I active use xforms technology since 2008 and I want to share my point of view. Xforms form for me is very very powerful technology for building big forms with complicated logic. Please refer e.g. to EU Commission e-forms like http://erasmus-plus.ro/erasmus-plus-eforms-application-guide/. Similar forms I and my coullegues implemented in xforms. And that's work currently only in FF3.6 with xforms plugin:/ If you want to see how it works feel free to create account and after login choose e.g. "The scolarship and training found" and then "Application forms". https://online.frse.org.pl. For what this introduction? As I was started to develope my first xforms I was suprised how easy it is. But it was only first impression, because I met a lot of problems and low productivity in developing, chaning and debuging: 1. you have to write xml (main instance, origin instance, other instances if necessary), xsd, xforms (and as in my case latex print tamplate too) file separatly. 2. if you want change structure of xml (e.g. rename some nodes) you must change manually xsd, xfoms and latex file too. You must update all binds and fields 3. You cannot reuse fragments of this files in another context becouse you must do the same as in point 2. 4. If you want to add some specific constuction e.g. repeat list that show only a few fileds on the list e.g. name and surname but you want add subform to edit more details each time you must write it again and again. Please imagine that in one form you have 20-30 of such constructions. 5. and a lot of other problems All this above is time consuming and causes many errors. So taking into account our problems we developed own framework that solved almost all problems: reusable code, easy in maintain, etc., If anyone is intrested in details I can prepare some complex examples. In attachment I added some code that is transformed via xslt to xforms, xml, xsd and latex template. The main features are: xpath independent bindings, field definition contains control type, label, nodename, xsd type, size in grid layout online and independent size in grid layout in latex, bind element, hint element. In last five years we build based on that framework more than 2000 diffrent forms. I think about publishing it on SF. Stephen Cameron said about AngularJS. I have attempted to implement xforms in AngularJS becouse of similarities. But AngularJS forms are quite poor in data binding. As I know exist only simple libraries that implement jsonpath (https://code.google.com/p/json-path/) < xpath 1.0. Xpath is the best and easiest way to go through data tree. Summarizing: Xforms is currently the best specification for big forms, but difficult to maintain. Xfomrs is a bed solution for small simple forms. Better use pure js or AnlugarJS. All this solutions according to me need framework and xforms needs client side implementation! The one last but promissing is XSLTForms. Regards Jaroslaw Kowalewski |
From: Jarosław K. <jar...@st...> - 2014-10-14 13:50:03
|
All, I active use xforms technology since 2008 and I want to share my point of view. Xforms form for me is very very powerful technology for building big forms with complicated logic. Please refer e.g. to EU Commission e-forms like http://erasmus-plus.ro/erasmus-plus-eforms-application-guide/. Similar forms I and my coullegues implemented in xforms. And that's work currently only in FF3.6 with xforms plugin:/ If you want to see how it works feel free to create account and after login choose e.g. "The scolarship and training found" and then "Application forms". https://online.frse.org.pl. For what this introduction? As I was started to develope my first xforms I was suprised how easy it is. But it was only first impression, because I met a lot of problems and low productivity in developing, chaning and debuging: 1. you have to write xml (main instance, origin instance, other instances if necessary), xsd, xforms (and as in my case latex print tamplate too) file separatly. 2. if you want change structure of xml (e.g. rename some nodes) you must change manually xsd, xfoms and latex file too. You must update all binds and fields 3. You cannot reuse fragments of this files in another context becouse you must do the same as in point 2. 4. If you want to add some specific constuction e.g. repeat list that show only a few fileds on the list e.g. name and surname but you want add subform to edit more details each time you must write it again and again. Please imagine that in one form you have 20-30 of such constructions. 5. and a lot of other problems All this above is time consuming and causes many errors. So taking into account our problems we developed own framework that solved almost all problems: reusable code, easy in maintain, etc., If anyone is intrested in details I can prepare some complex examples. In attachment I added some code that is transformed via xslt to xforms, xml, xsd and latex template. The main features are: xpath independent bindings, field definition contains control type, label, nodename, xsd type, size in grid layout online and independent size in grid layout in latex, bind element, hint element. In last five years we build based on that framework more than 2000 diffrent forms. I think about publishing it on SF. Stephen Cameron said about AngularJS. I have attempted to implement xforms in AngularJS becouse of similarities. But AngularJS forms are quite poor in data binding. As I know exist only simple libraries that implement jsonpath (https://code.google.com/p/json-path/) < xpath 1.0. Xpath is the best and easiest way to go through data tree. Summarizing: Xforms is currently the best specification for big forms, but difficult to maintain. Xfomrs is a bed solution for small simple forms. Better use pure js or AnlugarJS. All this solutions according to me need framework and xforms needs client side implementation! The one last but promissing is XSLTForms. Regards Jaroslaw Kowalewski |