Live data from Hacker News

Select Transform: JSON template over JSON

selecttransform.github.io

61–70 of 76 posts

Re: Select Transform: JSON template over JSON

#61

Hi, my name is Ethan. I'm the creator. I thought I would provide some context on why I wrote this library, and how I'm using this right now. So here it goes: Other than ST.js, I also work on another open source project called Jasonette ( https://www.jasonette.com ), which lets you write an entire native iOS/Android app in nothing but JSON markup. And when you can express the entire app logic--from model to view to co…

The project is interesting... But I don't understand your point about JSON vs JS.

1. You can store JS anywhere (all DBMS support text).

2. You can send it over the Internet... Like everything else nowadays.

3. You can compose JS easily.

4. You can validate JS using linters.

5. etc.

Besides... Aren't you only disguising functions in strings? You can eval strings anyway.

Re: Select Transform: JSON template over JSON

#62

Earlier quoted context omitted.

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

I hate those comma's, forgetting them or having too many. So therefore I use YAML. Still way easier to read. employees: - name: John Crichton gender: male - name: Aeryn Sun gender: female

I like YAML and do find it slightly easier to read than JSON. But it hasn't won the popularity contest (yet), for whatever reasons.

Re: Select Transform: JSON template over JSON

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

Exactly my observation! JSON became famous as a revolt against the complex XML ecosystem, but it reinvented a square wheel. YAML is no different - its specification and feature set is quite overwhelming.

There's so much quality work done with XML that all this effort is a complete waste. From streaming parsers to the XQuery, and great projects such as VTD-XML [0], it's sad to see us spinning wheels. I see TOML as another wasteful attempt at something that's only slightly better but requiring a new toolchain and an ecosystem.

[0]: https://vtd-xml.sourceforge.io/

Re: Select Transform: JSON template over JSON

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

I'm not sure why we didn't at least adopt JSON5 [0] or Hjson [1]!

[0]: http://json5.org/

[1]: http://hjson.org/

Re: Select Transform: JSON template over JSON

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

Yep. I agree. Although maybe XML schema ( https://www.w3.org/XML/Schema ) -> JSON Schema. And then there's also XQuery, DTDs, namespaces, entities,… which are also in need of reinventing I guess.

JMESPath [0], started by Amazon and used by Microsoft in Azure, is something that tries to accomplish some of the XQuery goals in a simpler way.

[0]: http://jmespath.org/

Re: Select Transform: JSON template over JSON

#66

Earlier quoted context omitted.

Or

I believe that was OP's point. Using the annotation you cannot add an attribute with subattributes. What if you wanted to add the employee's last six salaries. Suddenly you need to restructure your xml: John Crichton male 10000 10000 10000 Aeryn Sun female Using JSON, you just so: “salaries”: [10000,10000,10000] JSON is not only less verbose, it is also more flexible and easier to read and understand. You don’t have…

Why do you need to restructure the xml? You can just keep the attributes. To add the salaries there are quite a few options, as XML is just as flexible as well.

Using a List (XSD List) type:

    
      
      
    
And using mixed content (complexType):

    
      
        10000
        10000
        10000
      
      
    

Re: Select Transform: JSON template over JSON

#67
post #40

Earlier quoted context omitted.

Do people not remember how terrible XSLT was? I mean, sure, it could do the job, but did anyone ever sit down at a file of XSLT and think "yes, this is the best way this information about transforming this XML could be represented"? JSON is even less suitable for this. It's horrible to read this stuff, horrible to write.

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't ignore the terrible, terrible choice of making the transformation itself XML. It's completely unreadable and horrific to write.

Re: Select Transform: JSON template over JSON

#68

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

It's a lot easier to read when a data format is written in JSON, when a document format is written in JSON the reverse is the general order (minus incidents where the format is obnoxiously constructed so as to defy understanding by outside parties)

Re: Select Transform: JSON template over JSON

#69
post #36

Earlier quoted context omitted.

I kinda get this criticism, but this is also a bit like lamenting that we write the same libraries for different programming languages. I mean... yeah. Some ideas are good across protocols. That's why they're copied. On a merits-based thing, if you're just looking at XML, it has a lot of things going against it .If someone sends me something "in JSON", I can have a good guess what it'll look like. Not as much luck wi…

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

JSON has data types built into it, XML needs its data type understanding defined by an external technology - often in the form of an irritating schema language that is hard for many people to understand, extraordinarily verbose, and which also has the downside of not being able to describe many of the constraints often encountered in actual XML formats.

Re: Select Transform: JSON template over JSON

#70
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?)
Post reply on HN