7 ms·
Baseline for XML would be a document that doesn't use schemas, namespaces, attributes, or any of the SGML legacy stuff like DTDs and PCDATA. Such a document is
by andyjohnson0 4y ago
Baseline for XML would be a document that doesn't use schemas, namespaces, attributes, or any of the SGML legacy stuff like DTDs and PCDATA.
Such a document is essentially as simple as the equivalent JSON.
- hot_gril 4y agoEven that is more complicated than JSON.
- andyjohnson0 4y agoCare to elaborate?
- hot_gril 4y agoEvery key is written twice, for opening and closing. Keys can be duplicated, and in fact that's what you have to do if you want a simple list. There aren't numeric types, so you have to parse strings. It also looks horrible. <cds> <cd><title>Led Zeppelin II</title><artist>Led Zeppelin</artist><price>999</price></cd> <cd><title>La Brise<title><artist>Arax</artist><price>999</price></cd> </cds> or <cds> <cd> <title>Led Zeppelin II</title> <artist>Led Zeppelin</artist> <price>999</price> </cd> <cd> <title>La Brise<title> <artist>Arax</artist> <price>999</price> </cd> </cds> vs something like [ {"title": "Led Zeppelin II", "artist": "Led Zeppelin", "price": 999}, {"title": "La Brise", "artist": "Arax", "price": 999}, ] You can probably do better using XML attributes. But then you're using more features.
- taeric 4y agoIf we are complaining about the closing tags, might as well add that embedding newlines or quotes into JSON is less than pleasant. Which is to say, this feels a touch of a non-issue. Yes, writing it by hand can get tedious, but that is true of any and every format. Is why you will almost certainly reach for other formats if doing a long list of data. And each and every one of them will fail for some form of input in ways that is frustrating.
- hot_gril 4y agoWriting that JSON example by hand wasn't tedious. The XML example was, and the result is unreadable. It's important to be able to debug things easily. I'm going to manually type JSON when I'm testing an API, and I'm going to read the response. If you absolutely don't care about human interface, no reason to use XML either. It's meant to be more verbose. The XML tags will often dominate the size of the payload with things like `<question>Who</question>`, so you have to start thinking about shorter names. Yes JSON has a similar problem, but at least it's halved and you don't have to instruct everyone to call each list element "e". If you super care about size, you'll use protobufs or something.
- taeric 4y agoNot wrong, but also probably not really indicative of problems or actual use. And while I will be manually typing some data to go into an api for testing, I'm far more likely to by typing it in a thing that is was looser in what it accepts than a json document. Literally today just using dicts in python. And even then, my debugging is dominated by mistakes in data entry there. Also, I see you took it to be a full on defense of XML. I did not really intend it that way. I think both can be fine. And insisting on either is likely a mistake. I do find your nitpicks here amusing, still. Size of tag is just as obnoxious as size of key. And, though it can dominate the textual representation, there are clear ways to reduce that. Even knowing that BSON and Binary XML exist, though, I'd be hard pressed to say any project that failed because they weren't using them.
- hot_gril 4y agoJSON vs XML isn't going to make or break your project. But why would you use XML for data interchange. It makes sense for things like HTML where you're writing a document, but otherwise, it's usually just a needless burden. Like, if I were there when XMPP was created, yes I would have insisted on JSON. XML was a plainly bad choice. Edit: Oh, JSON didn't exist until a little later. Maybe something similar did.
- 4y ago
- deleted 4y ago[deleted]
- andyjohnson0 4y agoThanks. I get your point about the close element including the tag name - but that's the kind of detail I leave to the serialisation library, in the same way that the close scope token in json is different to the start scope token. As for "looks horrible"... well yeah, I always feel that xml looks "spikey" somehow. But I've been programming in curly-brace languages for 30+ years and I still find json harder to read than xml: I think my brain tries to interpret it as code, not data. I find xml easier to read (even when its unformatted) precisely because the close-tokens kind of document what element they're closing. Each to their own I guess. At least we're not stuck using ASN1.
- hot_gril 4y ago> At least we're not stuck using ASN1. Prepare for trouble, and make it double: http://xml.coverpages.org/dstc-xer2.html http://xml.coverpages.org/dstc-xer2.html
- datavirtue 4y agoAnd if someone is nice enough to stuff a NUL in the document, it all shatters.