Hacker News Reader

Attributes are intended to hold metadata, not data. It's not the fault of the format if someone chose to use it in a poor way.

You also need to distinguish the format itself from the various libraries that may be available to parse/process it in a given language. It doesn't always make sense, even when it's an option, to let the tail wag the dog and choose a language just because it has a nice library for something.

> Furthermore parsing JSON or YAML gives you the basic data types like lists and dictionaries

Well, maybe some library for some language does that, and if that is the language you are using, and that is all you need, then I suppose you are in luck. More generally you may want to use a format like XML or JSON to hold user defined types, which rather levels the playing field since there are few good libraries for this in any language,and you may need to roll your own (been there, done that).

> It's not the fault of the format if someone chose to use it in a poor way.

Which is why we've ended up with things like WSDL which define another layer on top of XML to make it actually usable for the thing it is used for. Hence the collective exhale when JSON showed up.

Again we come back to it being a markup language.

In markup, it's usually pretty clear what is data and metadata: <font style="bold">hello world</font> and not <font><style>bold</style>hello world</font> because you don't want the word "bold" to literally appear in the document.

In structured data, the distinction is redundant.

Not always.

For example, XML itself doesn't have types, so maybe you need to use attributes to store the data type (e.g. what if you need to do to lossless JSON <-> XML conversion).

and what is the difference between <data type="dict"> and <data><type>dict</type> and <dict>?

If you use tag "type" rather than attribute "type", then you are going to clash with representing data that itself needs to use tag "type".

> Furthermore parsing JSON or YAML gives you the basic data types like lists and dictionaries. Parsing XML gives you an AST that requires a lot more effort to turn into data in your domain.

More precisely: in XML, elements (nodes) are named/labeled. ("node-labeled graph") In JSON, keys (edges) are named. ("edge-labeled graph")

In programming, we need names for the fields in our structures (edges between objects), so JSON is a much better match than XML (which needs contortions to handle this use case -- e.g. by having nesting levels alternate between element=node and element=edge). Only in some object-oriented cases (which derived class should the deserializer construct?) do you care about node labels -- but usually that's in addition to edge labels, so a "_type" key in JSON is still easier than XML.

CSTML gets the best of both worlds https://docs.bablr.org/guides/cstml

Well, "easier" may well be "one less dimension to encode data" in this case.

Sure, this gives quite a few variations on how to serialize some data. But it's not like json's simpler approach would make data serialization universal, there are many different ways to encode the same thing.

Because SAX parsing is a thing, and the visitor pattern makes it easy to elide searches in sub-trees if an attribute does not match.

So if name == "foobar" then read; else ignore. For a 500 GiB XML file that makes a difference.

As for your other point about an "AST" (it's actually just a DOM.) That's the the benefit? And you're in for a surprise when you learn that reaching into a deeply-nested JSON structure deserialised into whatever memory format most appropriate for your pet language is also an abstract data type that you act on with getters/accessors/what-have-yous that is in all but name a DOM.

And we do have tools to deal with it: XSLT for transformation. For querying? XPath.

Cardinality is the easy way to resolve this. If the data has a cardinality of 1, it should be an attribute. If cardinality > 1, it should be a child element/node.

Not sure I understand. How do you represent an object nested in another object?

It’s not easy though. When we started with html we assumed images could only have one source. It was obvious that cardinality was 1. Later we realised we could have multiple versions of the same image. With audio tags that was resolved.

I’ve come to realise that it’s almost always a mistake to assume a cardinality of 1, unless it’s something that is defined to be artificially unique like the id attribute.

Interesting point of view. JSON is also not the right thing to use in many scenarios, but it is the de-facto standard now. Maybe something like protobuf is the way to go.

Length-limited, singular and scalar pieces of data can definitely be held in attributes. It is perfectly fine to have:

     <country name="Liechtenstein" rank="1" gdppc="141100"> 
        <neighbor name="Austria" direction="E"/>
        <neighbor name="Switzerland" direction="W"/>
     <country>

YAML made me not hate XML.

Agreed. Among text based formats, nothing I hate more than YAML.

That and all the proprietary formats we had to deal with before XML came along.

Sure. Standards like EDIFACT make XML seem like a big improvement.

XML is like violence. If it’s not solving your problem, you need to use more.

Not really. In C# I use a parsing library for which I just write a class and then the library automatically serializes the JSON into an instance of that class.

I can do the same thing with XML. Of course it doesn't necessarily go that smoothly with all xml, but as long as the xml is fairly simple like a JSON document would be it's totally fine. It's only when you start to use all the features of xml that don't fit neatly into a class model that it starts to get annoying. But if JSON serves your needs then simple xml does as well. I wouldn't use it because JSON works just fine but it's not as bad as people make it seem, unless people make it really bad.

That is actually a good approach that I have also used a lot: let the parsing library handle everything including the serialization and deserialization. But if you do that, why do you care that behind the scenes it is using JSON or XML or protobuf or something else?

Because at some point you have to debug stuff. And JSON is easier to read than XML to figure out where a problem might be.

I would even go as far to say that XML may very well be better in some cases, - here you have a schema most of the time, so you can often catch e.g. schema evolution failures at compile time.

This is much less common/less standardized with json.

JSON schema exists. If you restrict yourself to a sensible subset of XML features in your XML schema, you can have a 1:1 correspondence to JSON and JSON Schema. We do that at work. Due to historical reasons we have a XSD but provide the complimentary JSON Schema to those who wish to send us JSON.

The JSON is converted on the fly to XML based on the XSD so it can be ingested by our existing XML integration. Similar with return answers, response XMLs are converted on the fly based on the XSD to JSON.

JSON endpoints validate against the JSON Schema, also generated from the XSD at runtime, XML against the XSD of course.

We had a diverse set of XSDs but didn't have to tweak them to support JSON. We used restrictions and extensions, both simple and complex, we used min/max, enums, descriptions and examples and more, so not entirely boring XSDs.

We did establish some conventions, attributes turns the child element to an object and the attributes become properies, just simple stuff like that.

This way customers can hand us what they prefer generating and ingesting, and we don't have to worry about keeping two different schemas for the same endpoint in sync.

> Why is the country name an attribute but not the rank?

Perhaps because it's an example of what is possible in XML and how to parse it, and not, in fact, a particularly good or canonical example of XML?

I think GP’s question was rhetorical. They know it’s an example.

It's a very typical example. The real world does look like this.

So it was, in fact, designed correctly as an illustration.

Either way the context of that comment is "why does XML do this?" when in fact XML, itself, does not.

It allows both data and metadata; this is not a flaw, because it is not a pure data format.

You can choose to use those features correctly or incorrectly, and how you choose to do it is application-specific, because it is a format that is capable of producing both structured and semi-structured markup. Sometimes an ID is data; sometimes in the context of an application it is only metadata. It depends.

And that is putting aside that this complaint was used to mount a partial defence of YAML, which is one of the worst things the open source community has ever done to the world. YAML is never the answer.

I hate the X and L parts too. Just because you put a URL inside doesn't make the other side understand your structure. The features that try to make it extensible actually make it less so.

I can't think of any cases XML has helped, and plenty where it's massively gotten in the way. XMPP should've been json for instance. React used something like XML in structure for JSX but didn't actually use XML, so thank goodness we didn't have to put xmlns= all over it.