Hacker News Reader

My biggest gripe with XML has more to do with how data is structured: XML offers both tag attributes and child tags and when encoding data it's not obvious which one to use. You can also use multiple child tags and it's not obvious whether you should mix multiple kinds or not.

The usage is obvious when using XML as markup, but when used for data it's left to the one creating the particular spec.

You can have style guidelines, but other data formats don't really need that to answer those questions. More flexible is not always better, especially in languages.

>> XML offers both tag attributes and child tags and when encoding data it's not obvious which one to use.

>> The usage is obvious when using XML as markup, but when used for data it's left to the one creating the particular spec.

Either approach is valid. Having a choice about how to structure the data is not a bad thing.

My preferred approach is to use attributes for simple key-value pairs that are mainly used to select structured data found in child tags. If you have configuration data that is stored as XML, you could use attibutes to mark where the contained structured data should be used. For example: 1) language localization data could be stored stored in XML with attributes describing the language or locale; 2) build configuration settings might be stored in XML with attributes describing the target platform or CPU architecture.

For more formalized data formats, create an XML Schema that defines what the XML data should look like and then you can easily validate that the XML data is structured correctly and even generate parsers or XML to programming language bindings.

> Either approach is valid. Having a choice about how to structure the data is not a bad thing.

I though the point of using a well defined markup language was exactly that it imposed a clear structure on your data.

In another sense, xml gives no options: your data is going to live in a string.

>> I though the point of using a well defined markup language was exactly that it imposed a clear structure on your data.

A clear structure can be defined with an XML Schema Definition (XSD) document:

https://en.wikipedia.org/wiki/XML_Schema_(W3C)

An XML Schema Definition defines the structure and allowable content for a given XML document and allows XML data to be programmatically validated to ensure it adheres to the specified format and content.

>> In another sense, xml gives no options: your data is going to live in a string.

This is true. XML is inherently text-based. There are options for binary data formats depending on your needs.

"it's not obvious which one to use"

Perhaps this explains one system I saw that included entire encoded XML documents as attributes in other documents. On the plus side this embedding only went one level deep.

Now I'm curious. Is that Microsoft Office with embedded documents (e.g. a powerpoint presentation with a word document embedded)? I've never looked at how the pptx format contains the docx format internally.

I've seen it in XML-based docs showing example XML responses. Then somebody tried to document the doc-generating-tool and I think we all know how that went.

Child elements are different from attributes because elements can be structured (with attributes, other elements etc.) and repeated within the same parent element. On the down side, elements are a little more verbose and whitespace needs some attention.

This restricts attributes to zero or one unstructured values, which is more than a "style guideline".

It is questionable even in markup. Attribute restrictions (unique, can't be structured) gave rise to minilanguages

    class="foo bar"
    lang="en-US"
    style="margin:0;padding:0"

XSLT blows away promise of structured data with XPath and functions like concat in attributes. And it is a special case in DOM and XSLT making it much harder to manipulate.

Meanwhile <script> and <style> content hidden by default.

> Meanwhile <script> and <style> content hidden by default.

This is a fun thing that most people don’t realise. You can totally do this in CSS:

  head, title, script, style {
    display: block;
  }

And bam, your document title and the contents of any inline scripts and stylesheets are now visible on the page.

There's no ambiguity at all. Attributes are what fields are to a record; basically everything goes into attributes. Child elements are other records and are used when either there's more than one or their order is important or they also appear as children of other elements. Text is only used when there is actual content for humans that XML delineates; when XML is used as "application/xml" :) data there should be no text (unless parts of your data are such text).

More than "fields to a record" the difference between attributes and elements is that attributes cannot be nested. So in a sense if you are trying to write JSON in XML all base values should be in attributes.

The biggest advantage of JSON and YAML is that it has a very straight-forward object model consisting of literals, lists and dicts. All of these constructs map very easily to native data structures in most languages: you can just "load" and "save" an arbitrary json or yaml document.

The XML DOM is very different and does not map in an obvious way to objects in any programming language: you either use a DomDocument or object serialization for a subset of XML.

This alien object model makes programming with XML painful and verbose for no gain.

Sure: standards for xml schema and xpath are pretty nice but there are json equivalents which don't have to deal with elements and attributes. If standardization around YAML and XML was equally good would anyone pick XML?

> way too easy to forget what level of indentation you're currently at

This is easily solvable by tools. How is it worse than getting lost in braces or open/close tags?

> I think more projects (at least larger ones) should adopt their own DSL for configuration.

Please don't. JSON, YAML and XML config files can be easily and safely manipulated in all programming languages, for custom DSLs people end up using brittle regexps. It's not much better than putting config consts in a code file.

> This is easily solvable by tools.

Maybe, but I want it to work with standard tools. Most editors seem to arbitrarily jump back a couple of indentation levels e.g. if you add newlines somewhere. This obviously doesn't happen with JSON, since the editor won't have to guess whether you wanted to de-dent or not, it's all explicit. And I'm not making this problem up, it's literally a problem almost every time I have to edit some larger YAML file.

I'm not a fan of whitespace sensitivity in programming languages either, but at least Python etc. make a habit of discouraging 15 layers of indentation.

> Please don't. JSON, YAML and XML config files can be easily and safely manipulated in all programming languages, for custom DSLs people end up using brittle regexps. It's not much better than putting config consts in a code file.

What? Why would you parse a DSL with regex? I'm not saying people should write crappy DSLs. You can either write your own proper parser or you just use an embedded DSL, since there are multiple languages out there who are quite good at providing DSL support. The bonus is that it's often even type-safe, without having to be as mind-numbingly obtuse as XML.

On the note of type safety I can always suggest people to take a look at Dhall.

https://dhall-lang.org

Yes, this is something I've wanted to check out for a while now, I just don't think I could convince other people on any team to look at it. :D

I've had the same experience. Different editors and IDEs seem to handle YAML in wildly different ways. If you copy/paste a YAML stanza into a different document there is no telling how the editor is going to indent it. And trying to fix it can be something of a nightmare, especially when the editor indents different lines in the pasted text differently.

> What? Why would you parse a DSL with regex?

Let's say I want to process a nginx or apache config file programmatically to change a flag. Am I going to parse the full syntax? No, I'm going to hack something together with regexps.

> Sure: standards for xml schema and xpath are pretty nice but there are json equivalents which don't have to deal with elements and attributes.

Not quite there yet. Jsonpath is still not standardized (although a colleague of mine is working on it) and the many implementations out there disagree with each other.

(That said, I do agree with the general sentiment against XML)

There's DomDocument for json: https://docs.microsoft.com/en-us/dotnet/api/system.text.json...

For yaml: https://github.com/jbeder/yaml-cpp/blob/master/docs/Tutorial...

"The biggest advantage of JSON and YAML" should be put in a context of, "when working as a programmer with config files".

When we designed XML, we were working on things like a million pages of Unix documentation, or the flight manuals for aircraft, or research journal articles, or transcriptions of inscriptions found on fragments of ancient Greek pottery - lots of small similar documents, or very complex documents.

XML lets people who are not primarily programmers do sophisticated text processing and information design without depending on outside resources.

People who complain about XML being brittle are saying they want a system that forgives syntax errors, in the same way that JavaScript... doesn't... or that JAVA... doesn't... or that C... doesn't...or that Python... doesn't.

XML is unbeaten for the things it's good at. It was (still is, often) a problem that people used if in places where it wasn't so good. But that doesn't make it bad - it means you need to understand where it's good and where it isn't.

As the old saying goes - Use the right tool for the right the job!

> Also the point about the ad-hoc client validation doesn't seem right to me. If the server changes the XML response, the client may be able to fetch the updated schema (assuming the devs didn't forget to publish the update...), but then what? You still have to handle the new or updated fields in code somehow.

To be fair, there are often tools that will generate object definitions in the target language from an XML schema. It's not a perfect solution - you need to rebuild the project when upstream changes - but it's not like this hasn't been addressed. For what it's worth, Protobuf has the same property.

Yes. And then you end up with a domain-model that is badly designed because XML is not capable of expressing rich and nice-to-use data structures (as is possible both in OOP and in FP languages). You end up with lowest-common-denominator stuff, at which point you might just as well use JSON and parse it into something type-safe yourself (or not, and just use it as a [String: Any] dict).

>- It's as annoyingly verbose as Java is; I just get lost looking at all the tags (the namespaces don't help)

I guess if you take the effort to make it as annoyingly verbose it is, but in regards to namespaces for example Joe English's email on the psychopathologies of namespace usage http://www.flightlab.com/~joe/sgml/sanity.txt if followed for best practices also has the side effect of reducing much potential verbosity.

To me, one of the virtues of XML is that, if the server changes the XML response, you can capture it, and a human can eyeball parse it and figure out what went wrong, and figure out how to change the code on the receiving end to compensate. It's hard to automate, sure, but it's far better than having the server hand you some updated binary format.

Annoyingly verbose: Yup. Absolutely. I thought XML was kind of OK. Then I learned some about S expressions, and looked at XML with those eyes, and it was absolutely disgustingly verbose.

> To me, one of the virtues of XML is that, if the server changes the XML response, you can capture it, and a human can eyeball parse it and figure out what went wrong, and figure out how to change the code on the receiving end to compensate. It's hard to automate, sure, but it's far better than having the server hand you some updated binary format.

Maybe I'm misunderstanding, but it seems to me you can do the same thing with JSON.

Sure. It's just that, during the days that I had to do much with XML, JSON wasn't really a thing yet. I'm comparing XML to the binary formats that came before it (in wide use), not to JSON that came after it.

> - It's as annoyingly verbose as Java is

I reviewed an XML-based international industry 'standard' that allowed both verbose and terse versions of the same tags. Example files I saw tended to use the terse ones for common tags and the verbose ones for rare ones.

The last time I dealt with XML based services I tried to push "If we can't be right let's at least be consistent"

Matrix protocol uses JSON with namespaces, both Java-style, C and XML-style namespaces.

And because it's non-standard it's irritating. Every JSON parser doesn't have this built in, so you have to implement it at the application layer if you want it.