4 ms·

People say this, and yet XML's origins as a markup language make it baffling as a data format. No sane human being should choose a data format with such confusi

by strken 3y ago

People say this, and yet XML's origins as a markup language make it baffling as a data format. No sane human being should choose a data format with such confusion between properties that no user knows whether to go with <Foo> <Shininess>HIGH</Shininess> <Luck>7</Luck> </Foo> or <Foo shininess="HIGH" luck="7" /> and yet countless thousands decided to do just that, for reasons that are totally inexplicable to me. Obviously as a markup language this is fine; as a data format it's bizarre, since the division between attribute vs child doesn't match most in-memory data structures.

pydry 3y ago
Yeah, it's a weird attitude. XML died out because it was an overcomplicated design-by-committee mess. Quite apart from the fact that meant it wouldn't map cleanly to lists and hashmaps, necessitating a query language it also led to embarrassing debacles like the billion laughs vulnerability - problem in the very core of XML. With some niche exceptions where it has clung on, XML basically died. It's time to move on. The fact that we do similar sorts of stuff with JSON like data transformations and schema validation does not, in any way, shape or form, invalidate its flaws.
- baz00 3y ago
  XML is fine. The overcomplicated mess was the WS-* garbage.
smikhanov 3y ago
no user knows The described problem literally doesn't exist in XML. Your XML-validating editor will check your document against the schema and will not allow for an attribute where the sub-element is required and vice versa.
- tyingq 3y ago
  I believe they mean for designing the schema in the first place. Meaning the impedance match between JSON and their chosen language is usually more natural.
tannhaeuser 3y ago
I'm not disagreeing but the reason XML was used as data format is that it has native support in browsers (remember XML was created as a simplified SGML subset for eventually replacing HTML), the idea being that you can display service payloads via simple stylesheet applications or element replacement/decoration rather than having to rely on JavaScript or other Turing-complete environment for arbitrary scripting which was seen as having no place as a central technique in classic document-oriented browsing. JSON became only popular because of similar opportunistic effects (ie being already part of the stack via eval()). If you look at how typical non-JS backends such as Java or .net deal with service request/response data, there's absolutely no advantage for either JSON or XML - both are represented as class/structure and (de-)serialized via binding frameworks and annotations.
- strken 3y ago
  There's no particular machine advantage to any human-readable format over an equivalent binary format, sure. However, if you look at human-"readable" formats that predate XML (like HL7[0]) you can appreciate the advantages of a tree-like structure with labelled fields when it comes to human comprehension. I think XML is often difficult for humans to read, and certainly to write, and since this is the only reason to use either language it's an important factor. I guess you could argue we should all use Protocol Buffers, pickle, Thrift, etc.[1] and only switch to JSON for debugging. I wouldn't disagree. Protobuf is apparently faster than JSON in the browser. [0] See https://www.interfaceware.com/hl7-message-structure https://www.interfaceware.com/hl7-message-structure for an example message [1] I missed Corba and spent the early years of my professional life trying not to touch the SOAP, just in case I dropped it
- nrclark 3y ago
  JSON does have one advantage over XML: it maps cleanly onto primitive types in Python and many other languages. XML attributes don’t really have an unambiguous way to be represented using list and map primitives (other than maybe an “everything is a map” model, which sucks from a usability perspective).
  - aforwardslash 3y ago
the8472 3y ago
> since the division between attribute vs child doesn't match most in-memory data structures. vtables are attributes for pointers. hypergraphs (as used in some tagging systems) have attributes on everything, including attributes. CBOR has optional type-tags on its items.
baz00 3y ago
Actually you should never use attributes in XML at all to represent data. Your first example is correct. Everyone is just confused because people who didn't know this designed HTML. But also everyone is confused because HTML and XML aren't necessarily related other than some parentage in SGML.
- tannhaeuser 3y ago
  Nope. In markup, attributes are for "metadata", that is, anything not rendered to the reader/user, as opposed to (element) content. The entire purpose of markup is to provide a rich text format via decorating plain text usable from any text editor. Data exchange, or any other application where there is no concept of "rendering to the user", is no primary application for markup. If anything, what's wrong with HTML in this respect is that JavaScript and CSS can be put inline into content when these should always go into attributes and/or external resources linked via src/href attributes. And this flaw shows indeed where HTML deviates from SGML proper: when the style and script elements were introduced, their "content" needed to be put into SGML comment tags  such that browsers wouldn't render JavaScript snd CSS as text content. I mean, who came up with this brain-dead design? But CSS is a lost cause anyway. What does it tell you about its designers that they thought, starting with a markup language having pretty intense syntactic constructs already, to tunnel yet another item=value syntax in regular markup attributes? Like replacing <h2 bgcolor=black> by <h2 style="background-color: black"> and then claiming attributes are for "behavior" or whatever nonsense after the fact. Whoever came up with this clearly wasn't a CompSci person. And the syntactic proliferation in CSS completely became out of hand, for the simple reason that HTML evolution was locked down while W3C was focussed on XML/XHTML for over a decade, while the CSS spec process was lenient.
Communitivity 3y ago
I haven't used XML is a long while, but there was a trick I had when I designed schemas, back when I did use XML all the time. Use an attribute if the data is a primitive String, number, or boolean. Break into multiple attributes if the data is structured but has only one level and has few children. Otherwise use an element. The three rules are simple, but produce schemas easy to read, easy to maintain, and easy to implement against. One code smell is if you start winding up with tons of attributes on one element. That may mean you should break the logical concept that element represents into multiple concepts, have those concepts be nested elements, each with its related attributes.
OnlyMortal 3y ago
With the origins in SGML in the early 90s, there were some basic editors for manual creation. I suspect the popularity was due to the sax parser and “interop” between C++ and Java. To me coming from ObjC++, json is just a serialised dictionary.
olliej 3y ago
Honestly the worst xml I've encountered regularly is apple's xml plist format where dictionaries are <key>..</key> <value>..<value> <key>..</key> <value>..<value> ... Taking something that supports explicit structure and making it purely ordering based.

by strken 3y ago

pydry 3y ago

Yeah, it's a weird attitude. XML died out because it was an overcomplicated design-by-committee mess. Quite apart from the fact that meant it wouldn't map cleanly to lists and hashmaps, necessitating a query language it also led to embarrassing debacles like the billion laughs vulnerability - problem in the very core of XML. With some niche exceptions where it has clung on, XML basically died. It's time to move on. The fact that we do similar sorts of stuff with JSON like data transformations and schema validation does not, in any way, shape or form, invalidate its flaws.

baz00 3y ago
XML is fine. The overcomplicated mess was the WS-* garbage.

smikhanov 3y ago

no user knows The described problem literally doesn't exist in XML. Your XML-validating editor will check your document against the schema and will not allow for an attribute where the sub-element is required and vice versa.

tyingq 3y ago
I believe they mean for designing the schema in the first place. Meaning the impedance match between JSON and their chosen language is usually more natural.

tannhaeuser 3y ago

I'm not disagreeing but the reason XML was used as data format is that it has native support in browsers (remember XML was created as a simplified SGML subset for eventually replacing HTML), the idea being that you can display service payloads via simple stylesheet applications or element replacement/decoration rather than having to rely on JavaScript or other Turing-complete environment for arbitrary scripting which was seen as having no place as a central technique in classic document-oriented browsing. JSON became only popular because of similar opportunistic effects (ie being already part of the stack via eval()). If you look at how typical non-JS backends such as Java or .net deal with service request/response data, there's absolutely no advantage for either JSON or XML - both are represented as class/structure and (de-)serialized via binding frameworks and annotations.

strken 3y ago
There's no particular machine advantage to any human-readable format over an equivalent binary format, sure. However, if you look at human-"readable" formats that predate XML (like HL7[0]) you can appreciate the advantages of a tree-like structure with labelled fields when it comes to human comprehension. I think XML is often difficult for humans to read, and certainly to write, and since this is the only reason to use either language it's an important factor. I guess you could argue we should all use Protocol Buffers, pickle, Thrift, etc.[1] and only switch to JSON for debugging. I wouldn't disagree. Protobuf is apparently faster than JSON in the browser. [0] See https://www.interfaceware.com/hl7-message-structure https://www.interfaceware.com/hl7-message-structure for an example message [1] I missed Corba and spent the early years of my professional life trying not to touch the SOAP, just in case I dropped it
nrclark 3y ago
JSON does have one advantage over XML: it maps cleanly onto primitive types in Python and many other languages. XML attributes don’t really have an unambiguous way to be represented using list and map primitives (other than maybe an “everything is a map” model, which sucks from a usability perspective).
- aforwardslash 3y ago

the8472 3y ago

> since the division between attribute vs child doesn't match most in-memory data structures. vtables are attributes for pointers. hypergraphs (as used in some tagging systems) have attributes on everything, including attributes. CBOR has optional type-tags on its items.

baz00 3y ago

Actually you should never use attributes in XML at all to represent data. Your first example is correct. Everyone is just confused because people who didn't know this designed HTML. But also everyone is confused because HTML and XML aren't necessarily related other than some parentage in SGML.

tannhaeuser 3y ago
Nope. In markup, attributes are for "metadata", that is, anything not rendered to the reader/user, as opposed to (element) content. The entire purpose of markup is to provide a rich text format via decorating plain text usable from any text editor. Data exchange, or any other application where there is no concept of "rendering to the user", is no primary application for markup. If anything, what's wrong with HTML in this respect is that JavaScript and CSS can be put inline into content when these should always go into attributes and/or external resources linked via src/href attributes. And this flaw shows indeed where HTML deviates from SGML proper: when the style and script elements were introduced, their "content" needed to be put into SGML comment tags  such that browsers wouldn't render JavaScript snd CSS as text content. I mean, who came up with this brain-dead design? But CSS is a lost cause anyway. What does it tell you about its designers that they thought, starting with a markup language having pretty intense syntactic constructs already, to tunnel yet another item=value syntax in regular markup attributes? Like replacing <h2 bgcolor=black> by <h2 style="background-color: black"> and then claiming attributes are for "behavior" or whatever nonsense after the fact. Whoever came up with this clearly wasn't a CompSci person. And the syntactic proliferation in CSS completely became out of hand, for the simple reason that HTML evolution was locked down while W3C was focussed on XML/XHTML for over a decade, while the CSS spec process was lenient.

Communitivity 3y ago

I haven't used XML is a long while, but there was a trick I had when I designed schemas, back when I did use XML all the time. Use an attribute if the data is a primitive String, number, or boolean. Break into multiple attributes if the data is structured but has only one level and has few children. Otherwise use an element. The three rules are simple, but produce schemas easy to read, easy to maintain, and easy to implement against. One code smell is if you start winding up with tons of attributes on one element. That may mean you should break the logical concept that element represents into multiple concepts, have those concepts be nested elements, each with its related attributes.

OnlyMortal 3y ago

With the origins in SGML in the early 90s, there were some basic editors for manual creation. I suspect the popularity was due to the sax parser and “interop” between C++ and Java. To me coming from ObjC++, json is just a serialised dictionary.

olliej 3y ago

Honestly the worst xml I've encountered regularly is apple's xml plist format where dictionaries are <key>..</key> <value>..<value> <key>..</key> <value>..<value> ... Taking something that supports explicit structure and making it purely ordering based.