After I return my XML book I can use Python to make macros for LibreOffice.org. No love for Microsoft Excel, but it's a solution. I'll develop my own interface before using Excel.

That will show 'em!

Current project that I'm doing with a friend uses graphql whatever the **** that is exactly so when I figure it out in a couple weeks I'll report back.

It was more in response to the idea that form submissions should be JSON.

Would you rather:

Build a function that takes params, where that param is a map, and use your languages built-in functionality to extract the information?

or..

Send over JSON and use your language's shoddy JSON support to do non-native information extraction?

You've got to post data to your API somehow, it has to be in some format. What do you suggest? You don't get to pass "native" data exactly, you kind of have to choose some format or another. Ideally, it'll be one that is NOT specific to your programming languag n some way.

This is what SOAP tried to fix, btw, by having APIs define the types they accept and return, so that any SOAP client or server would be able to automatically convert between their own data and XML without the client or server needing to "know" how to do it. It just happened to be slow and ****ty and broken and etc.

Thanks for the clarification. I'm more bothered by the idea of doing manual intervention on these tokens rather than letting the system take care of it. It's in the bucket of stuff I'd rather not think about since adding the field just works.

I can figure there are situations where passing the token down the chain is correct, though I struggle to come up with specifics. I was under the impression that the token was being passed from form A to form B to form C, etc... that wouldn't make a lot of sense to me.

My comment was a response to this (I was semi-trolling here):

Using JSON is a lot of steps when you aren't actually using an API.

SOAP is absolutely horrible. I don't dispute that at all.

XML isn't great either, but at the least, you get the benefit of knowing that it is valid when it gets to your system.

Swagger can do the same thing if you bake it into your app (there are several swagger middleware modules for node).

My initial excitement for swagger has cooled after seeing it in action for a while. It definitely slows things down and I don't know if client devs really get enough out of it to make it worthwhile. For an internal client(s) consuming an internal API anyway. I can see how it's huge for an exposed API where anyone on the web can write a client.

I don't think you get any more of a guarantee with XML in this regard than you do with JSON? I can post whatever I want to a webserver and say "this is application/xml" and it'll take it just fine.

I mean, you have have a layer in there that reads and verifies the XML, but, if you use JSON, the same can/should be true. My API functions are not responsible for turning JSON into their native format, nor are they responsible for turning their returns into JSON, that's handled at a lower layer.

You don't get defined schemas or DTDs baked into JSON the way you do with XML. You have to write your own validator (or use something like swagger wired into your app server).

Similar to above - based on my experience when you only have internal clients consuming your internal API - validation isn't as important. Just let the app break and the client team can go look at the ICD or swagger and figure out what invalid request they're sending.

I'm using a lot of XML right now, not by choice, but the main benefit of it is that, when I successfully return XML from a function, I know that the structure is correct. That's one less wrong thing to think about. It really matters when the structure gets very large and I am dynamically generating XML.

In contrast, I've received mal-formed and altered JSON from well-known companies, and this happens silently in many cases. It's a matter of when and where you want the errors to occur. I'd prefer errors at the beginning, before it is sent to an API, lib, function, or end-user.

I don't think there is a major LOC difference between XML and JSON, though some languages handle JSON or XML more elegantly than other languages, no doubt.

I don't like either XML or JSON, really.

JSON is more popular because it's more easily scanned by humans, and the specs are simpler. I agree with your other point -- it is, in essence, the same reason why it's nice to have real types in a programming language. There are libraries that, given a spec object which defines your expected JSON type structure, will type check it for you, just like the XML.

I'm going with speed for my project, so I'll try both and see which is faster with benchmarks. It doesn't seem all that difficult to do both with the boost libraries. I'll figure-out validation w/ json (pre api). I mean, JSON is cuter, and XML is uglier, and there are more keystrokes if you're doing it manually, so perhaps JSON parsers are better. They certainly seem more flexible (though that flexibility can lead to bad data).

I think that depends on the complexity of the file you are looking at. JSON probably is easier for smaller files, but consider these excerpts, representing the exact same thing, from a very large file

http://www.utilities-online.info/xml...2d41-xmltojson

XML:

JSON:

I think the the XML wins here. The closing tags help navigate and still tell the story of what is happening here. The JSON is a bunch of closing brackets, aligned to what exactly?

If you are scanning one or the other, you can quickly figure out what the XML is doing, even if you can't see the beginning tags. Pretty printed JSON isn't helping much here.

edit: nevermind, my phone screwed up the layout, no tabs. Tapatalk problems.

The reason XML appealed to me was the purpose of schemas, XSLT, etc. For JSON I guess you write your own, or go with one less layer of validation, but it's not easier. That's what I was trying to say.

I don't entirely agree, but I also don't think a slavish xml-to-json translation is a particularly strong argument. I've written music software for years and I think this representation for a note is fairly awful.

Among other problems, the XML schema essentially loses type - you have things that are numbers that get represented as strings. The DTD may or may not make this plain in the XML, but it's something the parser has to "know" and in JSON, if done right, you'd just have proper numbers and strings.

I don't think the representation they chose is a particularly good one. "16th" for christ's sake. Laboriously pointing out step and note when pretty much everyone recognizes "C5". The inclusion of both duration and type is probably redundant unless this is meant to be an encoding of a performance where notes are not strictly tied to their official note length.

I would propose something like

I don't really know specifically what "beam" is supposed to represent but I suspect a proper version of it would be half the size.

One of the things that I hate about XML is these grand verbiose specifications. Turning it straight into JSON just makes a differently formatted version of the same verbiosity.

I'm going to also add that I think this is a good example of pitfalls of self-learning (maybe not Dave as much as leavesofliberty). Sure, you've demonstrated you can do something with XML - but you missed the bigger picture that its almost certainly not the right tool for the job.

but honestly, it's just not that important. my point was by way explanation of why json "won" the popularity battle, despite its inferior feature set.

2006 called and wants its xml vs json debate back.

Any idea why key:value pairs with some simple iconography for nested values never caught on? Something like
Car:
Car[color:red
Car[make:Honda
Car[interior:
Car[interior[fabric:leather

Something like that?

I've been hating XML since a lot earlier than 2006.

The XML in that example is MusicXML, which is the open data interchange for music notation engraving. MusicXML is used in pretty much everything, from MuseScore, Sibelius, Guitar Pro, etc.

I think there is some benefit to the style they use, but yes, you are correct, MIDI-style formats are cleaner.


***

I simply I don't think that JSON does a very good job of handling larger data dumps.

Here's another example, from the eBay API:

http://developer.ebay.com/devzone/re...rder__get.html

You'll have to scroll down a bit, but the payloads, both going out and coming in, are very large and difficult to deal with correctly. In the eBay API JSON example, the prices are strings, etc, so same issue as the XML irt to typing.

It's also impossible to appreciate how expansive and malleable that API is without taking in 50 orders at a time. Many items are optional, there's different outputs for different kinds of orders, and many other fun little traps.

I'm not saying that XML is better per se, and I believe JSON is better for smaller payloads than XML. I'm just not convinced that XML or JSON is particularly good for large structures.

As someone that has worked with large files (json/xml/whatever), I'm actually baffled by someone thinking that xml is better or even comparable.

It's worse in just about every imaginable way.

Edit: Well, I'd be baffled if I was having this conversation anywhere other than this thread. It has some real head turners at times.

Something that confused me in learning react is a former Facebook engineer calls JSX "XML under the hood" that's not right, correct?

It looks similar superficially, but JSX gets transpired by Babel into regular javascript. It's not the same for XML right?