xsltforms-support

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

[Alain C. <ala...@ag...>]

All,

Having a look at AB/2014-2015 Priorities/w3c work success 
(https://www.w3.org/wiki/AB/2014-2015_Priorities/w3c_work_success), I 
can read that XForms is one of the "failures to learn from".

Surely, there is a lot to be said about XForms as a failure. In this 
list of "failures", I would personally add XSLT and XQuery for very 
similar reasons, and surely SVG some years ago, if they all had to be 
considered as effective Web, or client-side, technologies.

What do you think? Shouldn't we write what has to be written?

Thanks!

-Alain

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

[Stephen C. <ste...@gm...>]

Hi Alain,

It would be interesting to hear people's views on the lack of 'success' of
XForms, from a historical perspective, from the people who put the effort
in to create the recommendation particularly.

Was the problem for XForms simply that two commercial giants had differing
approaches to the same problem of declarative forms?  Infopath from
Microsoft and XForms from (via) IBM? More recently Adobe has created
another forms solution too.

IBM put effort into browser based XForms as Ubiquity but that seemed to
gain little attention. There was another effort too in FormFaces. Once
Microsoft had a separate product line in Infopath there was little
incentive for them to add MVC style forms to Internet Explorer.

Personally it seems to me that the original spirit of browsers and of the
web in general for that matter is being lost to commercial interests. On
that basis it seems to me the W3C as an ultruistic organisation should just
make its own browser with ALL its XML standards implemented. It would find
a user-base I am sure, an Apache Licence seems fitting model.


Steve Cameron



On Sun, Oct 12, 2014 at 8:07 PM, Alain Couthures <
ala...@ag...> wrote:

>  All,
>
> Having a look at AB/2014-2015 Priorities/w3c work success (
> https://www.w3.org/wiki/AB/2014-2015_Priorities/w3c_work_success), I can
> read that XForms is one of the "failures to learn from".
>
> Surely, there is a lot to be said about XForms as a failure. In this list
> of "failures", I would personally add XSLT and XQuery for very similar
> reasons, and surely SVG some years ago, if they all had to be considered as
> effective Web, or client-side, technologies.
>
> What do you think? Shouldn't we write what has to be written?
>
> Thanks!
>
> -Alain
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://p.sf.net/sfu/Zoho
> _______________________________________________
> Xsltforms-support mailing list
> Xsl...@li...
> https://lists.sourceforge.net/lists/listinfo/xsltforms-support
>
>

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

[<bc...@sh...>]

On Sun, 12 Oct 2014 11:07:41 +0200
Alain Couthures <ala...@ag...> wrote:

> All,
> 
> Having a look at AB/2014-2015 Priorities/w3c work success 
> (https://www.w3.org/wiki/AB/2014-2015_Priorities/w3c_work_success), I 
> can read that XForms is one of the "failures to learn from".
> 
> Surely, there is a lot to be said about XForms as a failure. In this 
> list of "failures", I would personally add XSLT and XQuery for very 
> similar reasons, and surely SVG some years ago, if they all had to be 
> considered as effective Web, or client-side, technologies.
> 
> What do you think? Shouldn't we write what has to be written?
> 
> Thanks!
> 
> -Alain

Hello Alain

I am not an expert in the field, but I would not call XForms a failure.
Though I suppose it does depend on what the measure is.

If I were looking for something that would have made it come together
better, it would have been a tool, a main tool, a browser or something,
that brought all the ideas together in a demonstrable and useful
product.

Having said that, it is a shame it has all [arguably] struggled along
for reasons which I suspect are down to other commercial vested
interests by big players and their take-up or lack of, any proposed
standards adoption.

I still believe the XML based 'tools' (XForms, and associated concepts
e.g. XRX) are extremely important and its too easy to cast them off.

This comment from a reply to your post "...the W3C...should just
make its own browser with ALL its XML standards implemented." (Stephen
Cameron)  is not a shout without serious merit in my opinion too.

Not wishing to distract from supporting the previous idea, was not
XSmiles an attempt to have a go at doing the XML standards compliant
browser. 

Whatever, I still try to use XForms and it will only fail for me if the
clever and supportive open-source community minds keeping tools going
in some form or another, actually give up. To them, including you for
XSLTForms, I am grateful!

I wish there was some push by W3C to resurrect (if some feel it has had
its day) and bring it all together in a serious meaningful way. There
would always be a market I'm sure.....creative non-mainstream people
like to push boundaries   :-).

Regards
Chris H.

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

[Stephen C. <ste...@gm...>]

Hi Chris,

XSmiles is a Java project and just maybe that is a problem, no one is
interested in building (on) a browser using Java.

XQuery and XSLT do have some jobs market value still, but mainly in
integration work. That is a niche and in large part mostly filled by Saxon
I suspect.

The browser has become an application development platform, but the
approach used to do that is all Javascript based, XSLTForms itself is
Javascript in large part. and uses XSLT as a 'translator' to Javascript.

So, is there a place for such a browser as XSmiles but all C++? It could be
both a browser and a generic XML technologies library. I have a project
that I would love to do with such a beast, but maybe I am just one of those
"creative non-mainstream people (who) like to push boundaries" that you
mention, with no thought of the practicalities of cost and marketability.

Steve

On Mon, Oct 13, 2014 at 12:45 AM, <bc...@sh...> wrote:

> On Sun, 12 Oct 2014 11:07:41 +0200
> Alain Couthures <ala...@ag...> wrote:
>
> > All,
> >
> > Having a look at AB/2014-2015 Priorities/w3c work success
> > (https://www.w3.org/wiki/AB/2014-2015_Priorities/w3c_work_success), I
> > can read that XForms is one of the "failures to learn from".
> >
> > Surely, there is a lot to be said about XForms as a failure. In this
> > list of "failures", I would personally add XSLT and XQuery for very
> > similar reasons, and surely SVG some years ago, if they all had to be
> > considered as effective Web, or client-side, technologies.
> >
> > What do you think? Shouldn't we write what has to be written?
> >
> > Thanks!
> >
> > -Alain
>
> Hello Alain
>
> I am not an expert in the field, but I would not call XForms a failure.
> Though I suppose it does depend on what the measure is.
>
> If I were looking for something that would have made it come together
> better, it would have been a tool, a main tool, a browser or something,
> that brought all the ideas together in a demonstrable and useful
> product.
>
> Having said that, it is a shame it has all [arguably] struggled along
> for reasons which I suspect are down to other commercial vested
> interests by big players and their take-up or lack of, any proposed
> standards adoption.
>
> I still believe the XML based 'tools' (XForms, and associated concepts
> e.g. XRX) are extremely important and its too easy to cast them off.
>
> This comment from a reply to your post "...the W3C...should just
> make its own browser with ALL its XML standards implemented." (Stephen
> Cameron)  is not a shout without serious merit in my opinion too.
>
> Not wishing to distract from supporting the previous idea, was not
> XSmiles an attempt to have a go at doing the XML standards compliant
> browser.
>
> Whatever, I still try to use XForms and it will only fail for me if the
> clever and supportive open-source community minds keeping tools going
> in some form or another, actually give up. To them, including you for
> XSLTForms, I am grateful!
>
> I wish there was some push by W3C to resurrect (if some feel it has had
> its day) and bring it all together in a serious meaningful way. There
> would always be a market I'm sure.....creative non-mainstream people
> like to push boundaries   :-).
>
> Regards
> Chris H.
>
>
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://p.sf.net/sfu/Zoho
> _______________________________________________
> Xsltforms-support mailing list
> Xsl...@li...
> https://lists.sourceforge.net/lists/listinfo/xsltforms-support
>

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

[marcelo a. <cma...@gm...>]

Hi all, I would like to express what I think about this... For me XForms is
an incredible and powerful technology.  I love it and I will keep using it
as long as there are a community like this and, of course, the tools to get
the job done. In this respect, XSLTForms is all I need to build powerful
interfaces that are easy to code and maintain. That's it.
I am very grateful to Alain and all the people that make this possible.
So, Is XForms popular? No, Is  XForms a failure? Not at all.  This are not
the same thing.
Misquoting, I would say that, the reports of XForms's death are greatly
exaggerated ;)

cheers
marcelo





On Sun, Oct 12, 2014 at 4:52 PM, Stephen Cameron <ste...@gm...
> wrote:

> Hi Chris,
>
> XSmiles is a Java project and just maybe that is a problem, no one is
> interested in building (on) a browser using Java.
>
> XQuery and XSLT do have some jobs market value still, but mainly in
> integration work. That is a niche and in large part mostly filled by Saxon
> I suspect.
>
> The browser has become an application development platform, but the
> approach used to do that is all Javascript based, XSLTForms itself is
> Javascript in large part. and uses XSLT as a 'translator' to Javascript.
>
> So, is there a place for such a browser as XSmiles but all C++? It could
> be both a browser and a generic XML technologies library. I have a project
> that I would love to do with such a beast, but maybe I am just one of those
> "creative non-mainstream people (who) like to push boundaries" that you
> mention, with no thought of the practicalities of cost and marketability.
>
> Steve
>
> On Mon, Oct 13, 2014 at 12:45 AM, <bc...@sh...>
> wrote:
>
>> On Sun, 12 Oct 2014 11:07:41 +0200
>> Alain Couthures <ala...@ag...> wrote:
>>
>> > All,
>> >
>> > Having a look at AB/2014-2015 Priorities/w3c work success
>> > (https://www.w3.org/wiki/AB/2014-2015_Priorities/w3c_work_success), I
>> > can read that XForms is one of the "failures to learn from".
>> >
>> > Surely, there is a lot to be said about XForms as a failure. In this
>> > list of "failures", I would personally add XSLT and XQuery for very
>> > similar reasons, and surely SVG some years ago, if they all had to be
>> > considered as effective Web, or client-side, technologies.
>> >
>> > What do you think? Shouldn't we write what has to be written?
>> >
>> > Thanks!
>> >
>> > -Alain
>>
>> Hello Alain
>>
>> I am not an expert in the field, but I would not call XForms a failure.
>> Though I suppose it does depend on what the measure is.
>>
>> If I were looking for something that would have made it come together
>> better, it would have been a tool, a main tool, a browser or something,
>> that brought all the ideas together in a demonstrable and useful
>> product.
>>
>> Having said that, it is a shame it has all [arguably] struggled along
>> for reasons which I suspect are down to other commercial vested
>> interests by big players and their take-up or lack of, any proposed
>> standards adoption.
>>
>> I still believe the XML based 'tools' (XForms, and associated concepts
>> e.g. XRX) are extremely important and its too easy to cast them off.
>>
>> This comment from a reply to your post "...the W3C...should just
>> make its own browser with ALL its XML standards implemented." (Stephen
>> Cameron)  is not a shout without serious merit in my opinion too.
>>
>> Not wishing to distract from supporting the previous idea, was not
>> XSmiles an attempt to have a go at doing the XML standards compliant
>> browser.
>>
>> Whatever, I still try to use XForms and it will only fail for me if the
>> clever and supportive open-source community minds keeping tools going
>> in some form or another, actually give up. To them, including you for
>> XSLTForms, I am grateful!
>>
>> I wish there was some push by W3C to resurrect (if some feel it has had
>> its day) and bring it all together in a serious meaningful way. There
>> would always be a market I'm sure.....creative non-mainstream people
>> like to push boundaries   :-).
>>
>> Regards
>> Chris H.
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>> http://p.sf.net/sfu/Zoho
>> _______________________________________________
>> Xsltforms-support mailing list
>> Xsl...@li...
>> https://lists.sourceforge.net/lists/listinfo/xsltforms-support
>>
>
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> 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

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

[Stephen C. <ste...@gm...>]

Having twice tried to promote XForms in my workplace and not succeeded, for
me XSLTForms has failed in the 'marketplace of ideas'. But the IT road-side
is littered with such worthwhile efforts that lie discarded. Unless there
is a job or dollars in it most people are not interested. Have look at job
adds looking for AngularJS vs XForms experience.

XForms support in browsers is the subject of discussion though I think. If
Alain had not developed XSLTForms, XForms as it was envisaged, client-side
(RESTful), would be quite dead.

But things do sometimes 'rise from the dead' :)

On Tue, Oct 14, 2014 at 12:21 AM, marcelo alfaro <cma...@gm...> wrote:

> Hi all, I would like to express what I think about this... For me XForms
> is an incredible and powerful technology.  I love it and I will keep using
> it as long as there are a community like this and, of course, the tools to
> get the job done. In this respect, XSLTForms is all I need to build
> powerful interfaces that are easy to code and maintain. That's it.
> I am very grateful to Alain and all the people that make this possible.
> So, Is XForms popular? No, Is  XForms a failure? Not at all.  This are not
> the same thing.
> Misquoting, I would say that, the reports of XForms's death are greatly
> exaggerated ;)
>
> cheers
> marcelo
>
>
>
>
>
> On Sun, Oct 12, 2014 at 4:52 PM, Stephen Cameron <
> ste...@gm...> wrote:
>
>> Hi Chris,
>>
>> XSmiles is a Java project and just maybe that is a problem, no one is
>> interested in building (on) a browser using Java.
>>
>> XQuery and XSLT do have some jobs market value still, but mainly in
>> integration work. That is a niche and in large part mostly filled by Saxon
>> I suspect.
>>
>> The browser has become an application development platform, but the
>> approach used to do that is all Javascript based, XSLTForms itself is
>> Javascript in large part. and uses XSLT as a 'translator' to Javascript.
>>
>> So, is there a place for such a browser as XSmiles but all C++? It could
>> be both a browser and a generic XML technologies library. I have a project
>> that I would love to do with such a beast, but maybe I am just one of those
>> "creative non-mainstream people (who) like to push boundaries" that you
>> mention, with no thought of the practicalities of cost and marketability.
>>
>> Steve
>>
>> On Mon, Oct 13, 2014 at 12:45 AM, <bc...@sh...>
>> wrote:
>>
>>> On Sun, 12 Oct 2014 11:07:41 +0200
>>> Alain Couthures <ala...@ag...> wrote:
>>>
>>> > All,
>>> >
>>> > Having a look at AB/2014-2015 Priorities/w3c work success
>>> > (https://www.w3.org/wiki/AB/2014-2015_Priorities/w3c_work_success), I
>>> > can read that XForms is one of the "failures to learn from".
>>> >
>>> > Surely, there is a lot to be said about XForms as a failure. In this
>>> > list of "failures", I would personally add XSLT and XQuery for very
>>> > similar reasons, and surely SVG some years ago, if they all had to be
>>> > considered as effective Web, or client-side, technologies.
>>> >
>>> > What do you think? Shouldn't we write what has to be written?
>>> >
>>> > Thanks!
>>> >
>>> > -Alain
>>>
>>> Hello Alain
>>>
>>> I am not an expert in the field, but I would not call XForms a failure.
>>> Though I suppose it does depend on what the measure is.
>>>
>>> If I were looking for something that would have made it come together
>>> better, it would have been a tool, a main tool, a browser or something,
>>> that brought all the ideas together in a demonstrable and useful
>>> product.
>>>
>>> Having said that, it is a shame it has all [arguably] struggled along
>>> for reasons which I suspect are down to other commercial vested
>>> interests by big players and their take-up or lack of, any proposed
>>> standards adoption.
>>>
>>> I still believe the XML based 'tools' (XForms, and associated concepts
>>> e.g. XRX) are extremely important and its too easy to cast them off.
>>>
>>> This comment from a reply to your post "...the W3C...should just
>>> make its own browser with ALL its XML standards implemented." (Stephen
>>> Cameron)  is not a shout without serious merit in my opinion too.
>>>
>>> Not wishing to distract from supporting the previous idea, was not
>>> XSmiles an attempt to have a go at doing the XML standards compliant
>>> browser.
>>>
>>> Whatever, I still try to use XForms and it will only fail for me if the
>>> clever and supportive open-source community minds keeping tools going
>>> in some form or another, actually give up. To them, including you for
>>> XSLTForms, I am grateful!
>>>
>>> I wish there was some push by W3C to resurrect (if some feel it has had
>>> its day) and bring it all together in a serious meaningful way. There
>>> would always be a market I'm sure.....creative non-mainstream people
>>> like to push boundaries   :-).
>>>
>>> Regards
>>> Chris H.
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>>> http://p.sf.net/sfu/Zoho
>>> _______________________________________________
>>> Xsltforms-support mailing list
>>> Xsl...@li...
>>> https://lists.sourceforge.net/lists/listinfo/xsltforms-support
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>> 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
>
>

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

[Jarosław K. <jar...@st...>]

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

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

[William V. <wve...@vi...>]

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

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

[Stephen C. <ste...@gm...>]

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
>

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

[Paul V. <pva...@te...>]

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.

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

[William V. <wve...@vi...>]

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.

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

[Ihe O. <ihe...@gm...>]

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.

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

[Manuel L. <Man...@as...>]

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.

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

[Ihe O. <ihe...@gm...>]

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.


>
>

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

[William V. <wve...@vi...>]

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.

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

[Paul V. <pva...@te...>]

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.

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

[Manuel L. <Man...@as...>]

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.

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

[Ihe O. <ihe...@gm...>]

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.
>
>
>
>
>
>
>

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

[Stephen C. <ste...@gm...>]

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
>
>

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

[Mark L. <tin...@gm...>]

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
> 
> 

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

[Stephen C. <ste...@gm...>]

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
>>
>>
>

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

[michael odling-s. <mic...@xm...>]

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

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

[Ihe O. <ihe...@gm...>]

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.

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

[Stephen C. <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.

(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.
>
>
>
>

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

[Jarosław K. <jar...@st...>]

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