They’re not supposed to contain data, but some parsers will allow you to access what’s written into comments. And so, of course, someone made use of that and I had to extract what was encoded basically like that:
<!--
Host: toaster,
Location: moon,
--><data>Actual XML follows...</data>
My best guess is that they added this data into comments rather than child nodes or attributes, because they were worried some of the programs using this XML would not be able to handle an extension of the format.
In an ideal world, yes. In a locked down world where you have access only to 1/4 the codebase or your job is more ontology-focused, all you have access to might be the JSON. Leaving a comment or two about why a particular value or hierarchy is as it is is sometimes more clear than writing up a seperate README that no one will read
Hm? Comments are not data.
They’re not supposed to contain data, but some parsers will allow you to access what’s written into comments. And so, of course, someone made use of that and I had to extract what was encoded basically like that:
<!-- Host: toaster, Location: moon, --> <data>Actual XML follows...</data>My best guess is that they added this data into comments rather than child nodes or attributes, because they were worried some of the programs using this XML would not be able to handle an extension of the format.
They are useful metadata important to the longterm lifespan of the codebase
That’s why they make sense in code and config files. JSON is neither, despite the insistence of far too many people to write configuration in it.
In an ideal world, yes. In a locked down world where you have access only to 1/4 the codebase or your job is more ontology-focused, all you have access to might be the JSON. Leaving a comment or two about why a particular value or hierarchy is as it is is sometimes more clear than writing up a seperate README that no one will read