Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Select Transform: JSON template over JSON

selecttransform.github.io

Post reply on HN
Print view View original

71–76 of 76 posts

Re: Select Transform: JSON template over JSON

#71

Post by dragonwriter »

simonw wrote: post #44
jimktrains2 wrote: post #38

Earlier quoted context omitted.

Why is it super awkward and how does JSON solve this problem any better?

When you’re designing an XML schema, answering the question “should this be an attribute or a nested elember” is awkward because there is rarely an obvious correct answer. With JSON, the answer is always a name/value pair.

That's a problem with XML Schema, not XML.

A schema language in which subordinate values being presented as attributes vs. elements was a presentational option in the concrete XML representation rather than a dictate of the schema language would solve this simply. There are already multiple schema languages for XML; needing a better schema language doesn't begin to provide a reason for a different representation language, since schema and representation language are separate concerns.

Re: Select Transform: JSON template over JSON

#72

Post by arkh »

bryanrasmussen wrote: post #70
arkh wrote: post #15

Gotta love JSON. It's XML without the tools so you get to reinvent everything to pad your resume. XML -> JSON WSDL -> JSON schema XPath -> JSON path XSLT -> JSON template? SOAP -> Swagger and friends One or two decades from now there will be too many tools and things to learn about JSON so another generation will reinvent a new "perfect format for everything". And a new cycle will have started.

WSDL -> JSON schema is the wrong mapping, obviously should be XML Schema (WSDL is an awful web services things - so is there some combination of a router and JSON schema spec somewhere out there?)

> WSDL is an awful web services things

The thing is, when creating webservices you like creating tests. With WSDL you have tools which given a WSDL will generate a test-suite for you and some mocked services.

With JSON you'll have to hack-up something using Swagger.

Re: Select Transform: JSON template over JSON

#73

Post by eponeponepon »

Latty wrote: post #67
eponeponepon wrote: post #56

Earlier quoted context omitted.

XSLT was, and still is (imho) a great language - at least after 2.0. There's a steep learning curve full of false summits, for sure, but once you grasp it, there is always an elegant way of solving a problem using it. Sometimes there's even a fast way! Use of it in the wild, though, leaves a lot to be desired. The false summits lead people to write bad code, the bad code gives it a bad rep, the bad rep leads people t…

I just don't buy it - sure it can be used to do good things, but it's not about learning curves or "grasping it" - it's about "is this a good way for humans to write and read this transformation", and the answer is clearly no. XML is not a good form for a transformation language. It's not the quality of the code written in it or anything like that. Take XSLT and change the syntax, and sure, it might be great. You can…

Conversely, I personally find it very readable, and enjoyable to write; don't forget, when people talk about using the right tool for a job, it's not all about the language and the task - the dynamic between the person and the language is just as important :-)

Re: Select Transform: JSON template over JSON

#74

Post by tome »

dualogy wrote: post #58
tome wrote: post #55

Earlier quoted context omitted.

If you like writing let x = y { foo = foo y { bar = bar (foo y) + 1 } } instead of let x = over (foo.bar) (+1) y then more power to you!

A neat example indeed! Yeah that makes sense. Especially I guess in code-bases where such deeply-nested record updates abound everywhere repeatedly time-and-again --- have not run into such myself yet . Writing the above on-the-rare-occasion is hardly troublesome. But I get the idea there now. (Although in the above, half the verbosity comes from using records instead of ADTs' ctors and I believe aren't there common…

It's even worse if you don't have records!

    let x = Y (Foo (old_bar + 1) quux) baz
        where Y (Foo old_bar quux) baz = y

Re: Select Transform: JSON template over JSON

#75

Post by thepratt »

tchaffee wrote: post #46
jimktrains2 wrote: post #38

Earlier quoted context omitted.

Why is it super awkward and how does JSON solve this problem any better?

JSON is a lot easier to read. { "employees": [ { "name": "John Crichton", "gender": "male" }, { "name": "Aeryn Sun", "gender": "female" } ] } versus John Crichton male Aeryn Sun female

Wether it is easier to read or not is entirely subjective. There is no quantifiable measure to state either way. Both have their use-case; one now more than the other.

Re: Select Transform: JSON template over JSON

#76

Post by Latty »

eponeponepon wrote: post #73
Latty wrote: post #67

Earlier quoted context omitted.

I just don't buy it - sure it can be used to do good things, but it's not about learning curves or "grasping it" - it's about "is this a good way for humans to write and read this transformation", and the answer is clearly no. XML is not a good form for a transformation language. It's not the quality of the code written in it or anything like that. Take XSLT and change the syntax, and sure, it might be great. You can…

Conversely, I personally find it very readable, and enjoyable to write; don't forget, when people talk about using the right tool for a job, it's not all about the language and the task - the dynamic between the person and the language is just as important :-)

The vast majority of people find XSLT to be an unreadable mess - and for any non-trivial project that requires collaboration, just because it's possible for one person to like it doesn't make it a good choice.

If most people agree a representation is terrible, it's a bad choice for anything serious, because suddenly only a subset of your team or contributors can work on it effectively.

There is a reason XML isn't used as syntax for programming languages. Anyone claiming that an `if` construct, for example, is well represented by a mess of XML tags has a different brain to me and the vast majority of people I've met.

XSLT was meant to be a general-purpose tool. Having a syntax that the vast majority of people find incredibly hard to work with is clearly a huge problem with the spec.

Post reply on HN