5 ms·

I stopped reading at the example describing how to provide an org chart relation as XML. The argument here failed for me, and made the notion of what is "clean

I stopped reading at the example describing how to provide an org chart relation as XML. The argument here failed for me, and made the notion of what is "clean" code or "clean" structure even more subjective than ever. The JSON version of the employee org chart is much more semantic and human understandable (to me) as it "cleanly" describes the relationship for reports as a property called "reports" (for those who manage people - they have that property). But the org chart as XML was anything but obvious to my human eyes, as it was just nested employee elements and at first glance, looked like a single list of employees. Visually interpreting it to know who's a manager, and who reports to whom seems far more difficult in the XML. But, again, it's in the eyes of the beholder, and one person's clean solution is another person's confusing tangle of brackets.

vharuck 7y ago
My problem with the nested XML org chart is that relationships are described in the documentation instead of the code. The JSON version has more text but encodes more information. That's one less thing I need to write code for.
kgwxd 7y ago
They both looked fine to me but human readability shouldn't be the primary goal of a data format. I think the example is bad for both formats because it conflates tree data structures and logical hierarchy. The memory model of the application consuming the data would likely look like that, but that doesn't mean that's how it should be stored/transmitted, that should be probably be flattened, with each employee having a "manager" property.
- superqd 7y ago
  Yeah, that is a good point. It does seem to come up a lot in regards to data formats, that of how human readable they are. So I don't think it's without value, but shouldn't be what they are optimized for since it's usually software doing the reading most of the time, and not human eyes.

vharuck 7y ago

My problem with the nested XML org chart is that relationships are described in the documentation instead of the code. The JSON version has more text but encodes more information. That's one less thing I need to write code for.

kgwxd 7y ago

They both looked fine to me but human readability shouldn't be the primary goal of a data format. I think the example is bad for both formats because it conflates tree data structures and logical hierarchy. The memory model of the application consuming the data would likely look like that, but that doesn't mean that's how it should be stored/transmitted, that should be probably be flattened, with each employee having a "manager" property.

superqd 7y ago
Yeah, that is a good point. It does seem to come up a lot in regards to data formats, that of how human readable they are. So I don't think it's without value, but shouldn't be what they are optimized for since it's usually software doing the reading most of the time, and not human eyes.