5 ms·
You know, when XML looks like this, I don't mind it so much: <Employee name="Michael Scott" title="Regional Manager"> <Employee name="Dwight Schrute"
by OskarS 7y ago
You know, when XML looks like this, I don't mind it so much:
<Employee name="Michael Scott" title="Regional Manager">
<Employee name="Dwight Schrute" title="Ass. Regional Mgr" />
<Employee name="Jim Halpert" title="Head of Sales">
<Employee name="Andy Bernard" title="Sales Rep" />
<Employee name="Phyllis Lapin" title="Sales Rep" />
</Employee>
<Employee name="Pam Beesly" title="Office Administrator" />
</Employee>
The thing is, XML in the real world never looks like this. In the real world, XML has an avalanche of obscure namespaces, weird "<![CDATA" things, unreadable attributes, incomprehensible structure, and god knows what else.
The simplicity of JSON is an advantage: it prevents people from mucking it up with too much nonsense like this. Of course, you CAN make unreadble JSON as well, XML just makes it so much easier.
- tomschlick 7y ago> <Employee name="Dwight Schrute" title="Assistant to the Regional Mgr" /> Fixed that for you :) https://www.youtube.com/watch?v=wA9kQuWkU7I https://www.youtube.com/watch?v=wA9kQuWkU7I
- kbenson 7y agoSuch a missed opportunity to include Jim in the favorite movies examples with movies like Clear and Present Danger, Patriot Games, etc...
- deleted 7y ago[deleted]
- falcolas 7y ago> The simplicity of JSON is an advantage: it prevents people from mucking it up with too much nonsense like this. JSONs simplicity was out the window before it became a formal spec. The original designer of JSON omitted comments from the final spec because people were using them to create processing directives. There are multiple differing implementations of JSON parsers, the most notable differences between them being some allow comments while others treat them as errors. There's also JPATH, JSON Schema, and JSON Transform. JSON is the new XML. It has been and will continue to be abused to fit all the possible corner-cases, at the expense of simplicity and readability. Just like XML. EDIT: Oh, and instead of CDATA, we now simply base64 encode arbitrary objects and pack them into JSON encoded strings. Is this really an improvement?
- unlinked_dll 7y ago>EDIT: Oh, and instead of CDATA, we now simply base64 encode arbitrary objects and pack them into JSON encoded strings. Is this really an improvement? I think that's more of an indictment of HTTP than XML or JSON. Maybe we should have a better standard for exchanging non-textual data with websites.
- dfox 7y agoCDATA still does not allow you to include even arbitrary sequences of unicode codepoints, not to mention arbitrary binary data. On the other hand HTTP is in fact a binary protocol and there is perfectly good way to transport sets of binary objects with associated metadata: MIME multipart/whatever. With multipart/byteranges even being part of HTTP itself and multipart/form-data being one of the "core web technologies".
- delfinom 7y agoNo it's not. It's because people like to just pipe it into same request framework, get a json object and then later do base64_decode(json["binaryobject"]) instead of a separate http request to do binary transport which it can already do.
- mrlala 7y agoThat still looks extremely confusing.. if I didn't know who those people were, I would have a really hard time even noticing that there is a hierarchy in what you presented. And even still, that just doesn't look intuitive to me. Probably because there is no distinction between an employee and a list of employees linked to a parent employee?
- Mikhail_Edoshin 7y agoThe structure of XML (which element contains which) was meant to be used to link these elements to the underlying text they're marking up. When there's no text and just metadata (elements), there's no natural structure for them. It can still exist, of course, but what it means is totally up to the designer of this XML format. It's piggybacking the structural relation for something else. In this example it's piggybacked for "boss-employee" relation, but it could totally be flat like that: <Employees> <Employee id="1" name="Michael Scott" title="Regional Manager" /> <Employee id="2" boss-id="1" name="Dwight Schrute" title="Ass. Regional Mgr" /> <Employee id="3" boss-id="1" name="Jim Halpert" title="Head of Sales"> <Employee id="4" boss-id="3" name="Andy Bernard" title="Sales Rep" /> <Employee id="5" boss-id="3" name="Phyllis Lapin" title="Sales Rep" /> <Employee id="6" boss-id="1" name="Pam Beesly" title="Office Administrator" /> </Employees>
- smittywerben 7y agoIs this valid HTML, anyone?