3 ms·
XML suffers from too many options and useless bells and whistles. E.g. the attribute vs Parameter topic is a source of confusion, without adding much value, esp
by HdS84 3y ago
XML suffers from too many options and useless bells and whistles.
E.g. the attribute vs Parameter topic is a source of confusion, without adding much value, especially if the source and target are object oriented and/ or a relational db. What's the point?
Then there are namespaces, sure there are probably lots of places where you need to use them. But I never encountered a place where they are really needed, but because they are the default you need to work with them or your queries do not work. Super confusing for beginners and annoying as heck.
- crabbone 3y agoWhy is "how hard it is for beginners to understand a concept without reading a reference" a useful metric for measuring anything? So what if it's hard? -- Spend an hour with the reference document, and your problems will go away. In the days when XML was popular I've been more active in several Web forums that helped novice users with particular technology (and that included XML). Not a single confusion about XML namespaces came from someone who read the reference. Quoting the reference would be also a very efficient way to clear the confusion. Bottom line: it's not a problem worth mentioning. In the grand scheme of things an hour you'd have to spend reading the specification is a drop in a bucket compared to all the time you'd have to work with XML. It's a fixed-size effort that you have make once. Compare this to having to deal with bad "number" serialization that you have to deal in JSON every time in a new program that deals with JSON.
- toomim 3y ago> Why is "how hard it is for beginners to understand a concept without reading a reference" a useful metric for measuring anything? Two reasons: 1) Because it's unnecessary complexity. When you add unnecessary complexity into fundamental technology that everything uses, you've now made everything worse. It's like polluting the lake, and then ignoring the fact that beginners need to learn how to boil the water properly drinking it. 2) Because that prevents the technology from being adopted. Whether you think it's justified or not, beginners will choose the tech that's easier to use, and it will succeed. The market of technology adoption forces us to make things simple for beginners, and in the end, that's good for all of us.
- pasc1878 3y agoThe issue there is the complexity is necessary for some cases which are not met in trivial cases. E.g. When including element names from two sources. That is not a common use in json but with schemas you will come across it
- HdS84 3y agoAnd that could not be handled by making an optional namespace which can be used when it is actually needed? Even without namespaces, it's trivial to handle { "NamespaceA": {....}, "NamespaceB": {....}, } There is seldom need to mix it in the same object, and if you need that, you should think long and hard if you are on the right track.
- pasc1878 3y agoIsn't that what XML did - you only put the namespace in if it was needed. As for multiple ones in the same object it makes sense if you want to reuse a definition used elsewhere e.g. to add an address using a predefined address type. It is like using structures/records in programming languages but with no pointers for composition.
- javcasas 3y ago> Why is "how hard it is for beginners to understand a concept without reading a reference" a useful metric for measuring anything? So what if it's hard? -- Spend an hour with the reference document, and your problems will go away. Or spend 0 hours reading the JSON reference to reach the same result.
- Devasta 3y agoI manage a team of reporting analysts who look at XSLT transforms all day. None of them have programming backgrounds and they have never found XML namespaces to be a problem.