3 ms·
SGML (and descendants) is a markup language. It's in the name really. >XML/SGML are a very effective way of representing tree data Completely disagree: - It'
by simias 6y ago
SGML (and descendants) is a markup language. It's in the name really.
>XML/SGML are a very effective way of representing tree data
Completely disagree:
- It's not effective density-wise because the format is very verbose
- It's not effective parsing-wise because the format is very complicated.
- It's not effective human-wise because you have meaningless distinctions between attributes and child nodes which makes sense for a markup language but not for a serialization format. It's also very verbose which makes it annoying to read and write.
Imagine that you have an object like:
struct Object {
name: "foo",
}
Should you serialize like:
<object name="foo" />
Or:
<object> <name>foo</name> </object>
And to be clear, that's a rhetorical question. My point is that this distinction doesn't make a lot of sense for a serialization format and forces the developer to make pointless decisions. Here you might say that an attribute makes more sense, but then if later you realize that you can have several names you're screwed, because you either have to come up with your own custom format to store those in an attribute (coma-separated? But what if there's a coma in the name?) or split them off into child nodes.
It makes perfect sense for a markup language though, because there's (usually) a clear distinction between the textual and metatextual content. The stuff between the tags is meant to be displayed to the user, whereas the attributes are meant to be interpreted by the machine.
- DonHopkins 6y agoActually it's not a pointless distinction. If you care about the integrity of your string, you'd better use text nodes with CDATA, not attributes, because of the dreaded obscure XML feature called "Attribute Value Normalization". XML just tempts you to use attributes to represent strings, then kicks you in the ass when you least expect it by corrupting your data unexpectedly and unfairly but with full legal authority of the xml standard itself. I wrote about it in this other comment: https://news.ycombinator.com/item?id=26122107 https://news.ycombinator.com/item?id=26122107
- cdrini 6y agoAgreed; XML is best for document trees more than just generic tree data in general. I think the meaning between attributes/child nodes is pretty clear for like ~85% of use cases. Namely: attributes are for properties of the current node, child nodes are separate elements which are contained in the current node. I agree it can be complicated to parse, and don't agree it's exceptionally verbose. It is more verbose than say, a CSV or something, or than JSON (only because of the ending tags), but I wouldn't call it exceptionally verbose. That verbosity often makes things easier to read to than e.g. JSON, where you need a `type: "paragraph"` or equivalent on every element to simulate how HTML works. XML is better for document trees, JSON is better for generic tree data. (Note: XAML does have a nice duality between attributes and nodes (sort of) which is kind of interesting. It's been a while since I've used it though, so can't quite recall the details).