5 ms·

Everyone loves to hate on XML just because it can be verbose and some of the WS* protocols are complicated. But as a human-readable format it’s no harder to rea

by mikece 6y ago

Everyone loves to hate on XML just because it can be verbose and some of the WS* protocols are complicated. But as a human-readable format it’s no harder to read or parse than JSON and legacy application support is orders of magnitude better than JSON. I’m not saying we should all use it but we shouldn’t be hating it either.

zikzak 6y ago
Make these people debug doyne old EDI documents and all of a sudden XML doesn't seem so bad.
- twunde 6y ago
  who doesn't love x12, especially with its loops and segments?
dragontamer 6y ago
The issue with XML is that it was mostly pushed upon developers without any deeper understanding. So there's a ton of utterly crap XML applications out there with no rhyme or reason, and these crap XML enterprise apps are most developer's understanding of "real world XML". Similar to how terrible C++ code being all over the place is making people hate C++ the language. ------- XML can be used very well however: its use in Jabber / XMPP is clear and concise. XML Namespaces are needed due to the extensions of XMPP, and various programs can interact with the protocol. Specifications are clear, the ability to "stream" data is proven, different parser strategies have been implemented. Its clear that XML in this instance works, and works pretty well.
- vollmond 6y ago
 Around 2009, I worked on an application whose web interface and API were the same url -- it was served as an XML data file, with an XSLT transform to make it pretty for the browser. It was so comfortable.
 - eska 6y ago
 I really like the separation between the semantic content and the visualization there. HTML/JS/CSS throw everything together instead. But XSLT is nothing I want to have to work with..
- duxup 6y ago
 >crap XML enterprise apps are most developer's understanding of "real world XML" I mean if there's enough of it, it kinda becomes "real world XML". Right or wrong human's ability to actually use the tool or tech well is often where the bar is set. Could be a great idea but if folks can't do it... won't fly.
- commandlinefan 6y ago
 > without any deeper understanding I can't count how often I've seen XML that looked like this: <container name="containerName"> <attribute name="attrib1" value="value1" /> <attribute name="attrib2" value="value2" /> <attribute name="listAttibute" value="pipe|delimited|values" /> <attribute name="containedAttribute" value="<container name="otherContainer"..." /> ... </container> Which was, technically, XML (it even conformed to a schema!)... almost like "malicious compliance".
sjm 6y ago
XML's verbosity massively harms its human-readability in my opinion.
whynotminot 6y ago
Disagree--XML to me is much harder to read, if you're talking about human readable.
intrasight 6y ago
After 20 years of training, my meat-based XML parser is a well-tuned machine, and I prefer it over any of the other wannabes.
captrb 6y ago
Markup character and namespaces aside, I think what makes JSON easier to read is that it is more explicit about whether a child object is a singleton or a list, where XML requires you to consult the schema for minOccurs and maxOccurs.
Thaxll 6y ago
Hmm no, XML is 10x harder to read than JSON, period. It's just a ugly format with so much metadata information which are not human friendly. I think that's the main problem of XML it's not meant to be read by humans but people thought it was.
- jandrese 6y ago
 The primary problem with XML is that it's a document markup language being used to do data serialization. Schemas were bolted on after the fact to add enough metadata for data serialization, but that's a whole lot of added complexity on top of the already complex process of parsing a lightly specced document. So you have an already complex document parser (which you are using only a fraction of the full functionality!) with the added complexity of a schema system layered on top. This is why JSON took off so fast, it ditched the whole document part and just gave you the data.
- mikece 6y ago
 There's a huge difference between an XML document type designed by committee and something utilitarian used by an app developer. For example: <items> <item id="1" attr1="value 1" attr2="value 2" attr3="value 3" /> <item id="2" attr1="value 1" attr2="value 2" attr3="value 3" /> <item id="3" attr1="value 1" attr2="value 2" attr3="value 3" /> <item id="4" attr1="value 1" attr2="value 2" attr3="value 3" /> <item id="5" attr1="value 1" attr2="value 2" attr3="value 3" /> </item> It's not something that an IBM committee would have come up with but it fits the needs of an application. If XML has an "intrinsic fault" it's related to DTDs and namespaces which allow for the creation of horrible, complex monstrosities. XML can be every bit as stripped down and to-the-point as JSON, trading the curley braces for angle brackets. JSON's best point is that it doesn't support any of this needless complexity but it's still easy enough, with enough nested objects and arrays, to make something that's effectively not readable by a human.
 - dragontamer 6y ago
 > It's not something that an IBM committee would have come up with but it fits the needs of an application. Items can be order-dependent in XML. So the "id=1" thing is still superfluous. See xs:sequence. (In contrast: xs:all declares something to be order independent). If you were doing XML for your own apps, I think xs:sequence items simplify parsing grossly. Ex: if you have Address, maybe you always want "Street", then "Zip Code", then "State". <Address> <Street> 1234 Blah Street </Street> <City> Springfield </City> <State> Whatever </State> <Zip> 55555 </Zip> </Address> By declaring that Street -> City -> State -> Zip must happen in that particular order, you can grossly simplify the parser's job when reading such data in. (Or writing it out). -------- If there are multiple People at this address, you could (and probably should) just list them out in order. <Address> <Street> 1234 Blah Street </Street> <City> Springfield </City> <State> Whatever </State> <Zip> 55555 </Zip> <People> Marge Homer Lisa Bart Maggie </People> </Address>
legulere 6y ago
It’s made for documents. It just doesn’t fit to general data structures. For instance when do you put class members in elements and when in attributes?
marcosdumay 6y ago
Yes, XML is verbose. It's also highly redundant (so it basically can't be hand written), undesrpecified (do I put this value as an atribute, value, or sub-element?), underpowered (how does it represent numbers? Byte streams?), complicated (have you ever created a DTD by hand?), and just out badly designed. Of course, JSON and YAML share some of those same problems, and add some different ones. But the complaints about XML aren't some superfluous opinions about how it looks.
- Spivak 6y ago
  The under-specified thing I think is funny because it’s the source of pretty much all the bad XML you see in the wild. For being an entirely tree oriented format it’s tragic flaw is that XML can’t actually represent nested dicts (or arrays for that matter) which turned out to be the data structures people actually wanted to work with. Oh there are lots of ways to beat XML into looking like it can do it but they’re all bad, break all the actual semantics of XML and turn a nice deserialization story of a tree where each node is a complete thing into mess. Turns out that very few people actually needed a tree of heterogeneous string k-v pairs.
- GoblinSlayer 6y ago
  https://www.w3.org/TR/xmlschema-2/#built-in-primitive-datatypes https://www.w3.org/TR/xmlschema-2/#built-in-primitive-dataty... For comparison, time formats in JSON are all over the place.
hinkley 6y ago
The attribute versus child conundrum in XML specification is largely absent in JSON. Ordered versus unordered children is still a puzzle to sort out but more of a special case. In XML, there was always some motherfucker trying to stuff CSV into an attribute. And the difference between ID as specified and ID as implemented lead to a lot of problems, reaching its zenith (or maybe nadir?) in the XML Signature spec.
- GoblinSlayer 6y ago
  How would you represent CSV in JSON?
  - krapp 6y ago
    An array of maps - each map is a row, each key a column.
    - petre 6y ago
      Or an array of arrays with a TOC containing the keys to index mapping. Keeps the column order and it's more compact because it omits the keys in the data.
  - hinkley 6y ago
    I meant the specific case of someone trying to stick three values into an attribute but the other responder covered the general case. If you need three values use an array (or in xml, child element)

by mikece 6y ago

zikzak 6y ago

Make these people debug doyne old EDI documents and all of a sudden XML doesn't seem so bad.

twunde 6y ago
who doesn't love x12, especially with its loops and segments?

dragontamer 6y ago

The issue with XML is that it was mostly pushed upon developers without any deeper understanding. So there's a ton of utterly crap XML applications out there with no rhyme or reason, and these crap XML enterprise apps are most developer's understanding of "real world XML". Similar to how terrible C++ code being all over the place is making people hate C++ the language. ------- XML can be used very well however: its use in Jabber / XMPP is clear and concise. XML Namespaces are needed due to the extensions of XMPP, and various programs can interact with the protocol. Specifications are clear, the ability to "stream" data is proven, different parser strategies have been implemented. Its clear that XML in this instance works, and works pretty well.

vollmond 6y ago
Around 2009, I worked on an application whose web interface and API were the same url -- it was served as an XML data file, with an XSLT transform to make it pretty for the browser. It was so comfortable.
- eska 6y ago
  I really like the separation between the semantic content and the visualization there. HTML/JS/CSS throw everything together instead. But XSLT is nothing I want to have to work with..
duxup 6y ago
>crap XML enterprise apps are most developer's understanding of "real world XML" I mean if there's enough of it, it kinda becomes "real world XML". Right or wrong human's ability to actually use the tool or tech well is often where the bar is set. Could be a great idea but if folks can't do it... won't fly.
commandlinefan 6y ago
> without any deeper understanding I can't count how often I've seen XML that looked like this: <container name="containerName"> <attribute name="attrib1" value="value1" /> <attribute name="attrib2" value="value2" /> <attribute name="listAttibute" value="pipe|delimited|values" /> <attribute name="containedAttribute" value="<container name="otherContainer"..." /> ... </container> Which was, technically, XML (it even conformed to a schema!)... almost like "malicious compliance".

sjm 6y ago

XML's verbosity massively harms its human-readability in my opinion.

whynotminot 6y ago

Disagree--XML to me is much harder to read, if you're talking about human readable.

intrasight 6y ago

After 20 years of training, my meat-based XML parser is a well-tuned machine, and I prefer it over any of the other wannabes.

captrb 6y ago

Markup character and namespaces aside, I think what makes JSON easier to read is that it is more explicit about whether a child object is a singleton or a list, where XML requires you to consult the schema for minOccurs and maxOccurs.

Thaxll 6y ago

Hmm no, XML is 10x harder to read than JSON, period. It's just a ugly format with so much metadata information which are not human friendly. I think that's the main problem of XML it's not meant to be read by humans but people thought it was.

jandrese 6y ago
The primary problem with XML is that it's a document markup language being used to do data serialization. Schemas were bolted on after the fact to add enough metadata for data serialization, but that's a whole lot of added complexity on top of the already complex process of parsing a lightly specced document. So you have an already complex document parser (which you are using only a fraction of the full functionality!) with the added complexity of a schema system layered on top. This is why JSON took off so fast, it ditched the whole document part and just gave you the data.
mikece 6y ago
There's a huge difference between an XML document type designed by committee and something utilitarian used by an app developer. For example: <items> <item id="1" attr1="value 1" attr2="value 2" attr3="value 3" /> <item id="2" attr1="value 1" attr2="value 2" attr3="value 3" /> <item id="3" attr1="value 1" attr2="value 2" attr3="value 3" /> <item id="4" attr1="value 1" attr2="value 2" attr3="value 3" /> <item id="5" attr1="value 1" attr2="value 2" attr3="value 3" /> </item> It's not something that an IBM committee would have come up with but it fits the needs of an application. If XML has an "intrinsic fault" it's related to DTDs and namespaces which allow for the creation of horrible, complex monstrosities. XML can be every bit as stripped down and to-the-point as JSON, trading the curley braces for angle brackets. JSON's best point is that it doesn't support any of this needless complexity but it's still easy enough, with enough nested objects and arrays, to make something that's effectively not readable by a human.
- dragontamer 6y ago
 > It's not something that an IBM committee would have come up with but it fits the needs of an application. Items can be order-dependent in XML. So the "id=1" thing is still superfluous. See xs:sequence. (In contrast: xs:all declares something to be order independent). If you were doing XML for your own apps, I think xs:sequence items simplify parsing grossly. Ex: if you have Address, maybe you always want "Street", then "Zip Code", then "State". <Address> <Street> 1234 Blah Street </Street> <City> Springfield </City> <State> Whatever </State> <Zip> 55555 </Zip> </Address> By declaring that Street -> City -> State -> Zip must happen in that particular order, you can grossly simplify the parser's job when reading such data in. (Or writing it out). -------- If there are multiple People at this address, you could (and probably should) just list them out in order. <Address> <Street> 1234 Blah Street </Street> <City> Springfield </City> <State> Whatever </State> <Zip> 55555 </Zip> <People> Marge Homer Lisa Bart Maggie </People> </Address>

legulere 6y ago

It’s made for documents. It just doesn’t fit to general data structures. For instance when do you put class members in elements and when in attributes?

marcosdumay 6y ago

Yes, XML is verbose. It's also highly redundant (so it basically can't be hand written), undesrpecified (do I put this value as an atribute, value, or sub-element?), underpowered (how does it represent numbers? Byte streams?), complicated (have you ever created a DTD by hand?), and just out badly designed. Of course, JSON and YAML share some of those same problems, and add some different ones. But the complaints about XML aren't some superfluous opinions about how it looks.

Spivak 6y ago
The under-specified thing I think is funny because it’s the source of pretty much all the bad XML you see in the wild. For being an entirely tree oriented format it’s tragic flaw is that XML can’t actually represent nested dicts (or arrays for that matter) which turned out to be the data structures people actually wanted to work with. Oh there are lots of ways to beat XML into looking like it can do it but they’re all bad, break all the actual semantics of XML and turn a nice deserialization story of a tree where each node is a complete thing into mess. Turns out that very few people actually needed a tree of heterogeneous string k-v pairs.
GoblinSlayer 6y ago
https://www.w3.org/TR/xmlschema-2/#built-in-primitive-datatypes https://www.w3.org/TR/xmlschema-2/#built-in-primitive-dataty... For comparison, time formats in JSON are all over the place.

hinkley 6y ago

The attribute versus child conundrum in XML specification is largely absent in JSON. Ordered versus unordered children is still a puzzle to sort out but more of a special case. In XML, there was always some motherfucker trying to stuff CSV into an attribute. And the difference between ID as specified and ID as implemented lead to a lot of problems, reaching its zenith (or maybe nadir?) in the XML Signature spec.

GoblinSlayer 6y ago
How would you represent CSV in JSON?
- krapp 6y ago
  An array of maps - each map is a row, each key a column.
  - petre 6y ago
    Or an array of arrays with a TOC containing the keys to index mapping. Keeps the column order and it's more compact because it omits the keys in the data.
- hinkley 6y ago
  I meant the specific case of someone trying to stick three values into an attribute but the other responder covered the general case. If you need three values use an array (or in xml, child element)