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

On Thu, Oct 16, 2014 at 3:46 PM, Manuel Lautenschlager <
Manuel.Lautenschlager@ascio.com> wrote:

>  What is lightweight?
>
>
>
> For me lightweight is: Parsing takes only little resources.
>

I'm not sure why we are bothering about how much work the machine does
unless we have a specific performance problem so I smell a red herring here
....but ..... doesn't that depend to extent on what you are running in your
environment.

If you are running Python or R or anything other than javascript in
addition to your interpreter you also have to load a JSON library.



> Implementation is easy with a few lines of code. Only necessary
> functionality.
>

Well that depends on whether one believes that transformation's are
necessary functionality because (discounting the efforts of the XML
community i.e xslt3 json doesn't have a proper transformation language).

It also depends on whether one believes that a query language is necessary
because (discounting the efforts of the XML community i.e jsoniq) json
doesn't have a proper query language.

So what is left of that argument..... that being able to do sod-all is a
virtue. Nah! Rather you have to write an application program for everything
- we've known for 35 years (at least) that's a bad idea. For one thing it
destroys data independence because people will tend to tightly couple their
code to the extant data model (if for no other reason then the obsession
with "efficiency").



>  Not lightweight is: Very complex framework that tries to cover
> everything.
>
>
>

The fallacy in there is that because the framework allows you to "cover
everything" you have to. That's not true. There is no rule that says your
XML must have a schema. There is nothing stopping you from writing a
transformation to create a simpler XML subset if it will do the job.



>  I’m sure XML needs a few more lines to implement than JSON.
>

It's a semantically  richer data format, that's not unreasonable.


>  But what really is heavyweight are many standards. Like SOAP and XFORMS.
>
>
 The JSON world doesn’t have this problem, they don’t have  standards like
> XForms. (And no alternative)
>

The heavyweight lightweight thing is because  JSON  world is probably
occupied with comparatively trivial data models. Murex, XBRL, Biztalk, UBL
are not suddenly going to become lightweight if they were converted to
JSON. But the real fallacy is that something implemented in XML is
necessarily complex or heavyweight. Suppose you don't need schemas for a
particular JSON implementation. Chances are you wouldn't need them for an
XML implementation either but if ever you did in the future you won't find
that you have taken a long journey up s**t creek and thrown away your
paddle.

XForms is a ambitious . It's complexity is not a function of the data model
and one is  not compelled to use every facility in the standard.


>  You don’t need to learn how to use XForms. You need a form, you can
> start right on with a language you know (Javasript)
>
> People use other libraries to create forms, like AngularJS, and have a
> handmade component for each control.
> Actually every developer/company has its own UI-Style, and so they can
> create the Framework they need.
> Often it’s only small things that XForms can’t do. Like working with
> Websockets. Interactive status for an order form.
>
>
> With XForms the standard tells you how to work. With that you always have
> limitations.
>
> I accepted these limitations with the benefit that I am working with a
> standard.
>
> That “should” mean: sustainability, better support and documentation, many
> different applications you can run your code on.
>
>
>
> Unfortunately the reality is, that people are talking about dead
> standards, just when I am happy with them.
>
> I must say it took a while until I got used to XForms. For me that was
> investing lots of time.
>
>
>
> I used Betterform, which is the opposite of lightweight. But it is cool.
> The disadvantage is: When you work with the XForms language,
>
> It’s a big step adding new components and scripts. This is much easier
> when you build up your UI from scratch.
>

Are you sure that's a problem caused by the XForm standard. I recall that
when I built an XForm I was able to modularize much of the code and the
ability to deploy XSLT transformations was a key part of that.


>  That is the problem with standards that cover almost everything. You get
> used to it, and try to do everything with the standard.
>
> Otherwise you can’t port it to another platform.
>
>
>
> BTW. Just because somebody of W3C says it’s dead, it doesn’t need to be
> dead or a failure. But except of the XML-Community, nobody knows XForms.
>
> I like XForms and I hope that it’s not dead!
>
>
>
> Manuel
>
>
>
> Ps.: When tools can do less, you need to learn less. That why people use
> JSON
>

Being able to do sod-all is only a virtue if you actually need to do
sod-all.

I think most of the claims emanating from the JSON community do not
withstand scrutiny or like for like comparisons. To me XForms's biggest
crime is that it is a declarative technology (yes it can be  complex but so
are lot's of over things) and alot of programmers are not comfortable with
something that is not inherently procedural. Heck they even created
languages to proceduralize SQL the only declarative language that managed
to slip under the cover.


>
>