Hacker News Reader

Comment by mikece | Hacker News Reader

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.

View on HN

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.

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.

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..

>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.

> 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="&lt;container name=&quot;otherContainer&quot;..." />
       ...
     </container>

Which was, technically, XML (it even conformed to a schema!)... almost like "malicious compliance".

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.

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.

https://www.w3.org/TR/xmlschema-2/#built-in-primitive-dataty...

For comparison, time formats in JSON are all over the place.

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.

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.

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.

> 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>
      <p> Marge </p>
      <p> Homer </p>
      <p> Lisa </p>
      <p> Bart </p>
      <p> Maggie </p>
    </People>
    </Address>

JSON does support namespaces (and comments) you just roll them by hand (ad hoc).

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.

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

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

who doesn't love x12, especially with its loops and segments?

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.

How would you represent CSV in JSON?

An array of maps - each map is a row, each key a column.

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.

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)

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.

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?

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

Reply on news.ycombinator.com