3 ms·

I've never really subscribed to the mindset of XML for it has many disadvantages (the verbosity, the complexity of DTD, the tendency for documents which are too

• beagle3 10y ago
  > I do subscribe to namespaces, since it allows global referencing of names I have been forced to use XML one way or another for a variety of uses (mostly integration, not document storage - but still), and have not ONCE had a use for namespaces or multiple DTDs in a single document. I suspect no one has statistics, but I wouldn't be surprised if this is true for 99.9% of {users,documents,systems} - which, if true, means that 1/1000 burdens the rest needlessly. But of course, this is mere speculation. > I also do subscribe to formal grammars, mature standards, and good documentation. XML is enticing by appearing to have those, but it actually doesn't, as Naggum articulated in[0]. XML schemas can describe a superficial structure, but not anything non-trivial and definitely not any semantics. Naggum is entertaining though he holds nothing back, see e.g. [1]. > It's just that I think XML got an undeserved bad reputation and many of the 'good parts' have been forgotten. The problem with XML is that, like lawyers, 95% of the population gives an undeserved bad reputation to all the rest. XML did have some good ideas, but they are almost nowhere to be find in practice. > This allows us to connect, say, 'com.facebook:Person' with 'com.google:Person' with a global equivalence relation. It allows us to specify bridges between standards. No it doesn't, unless they are semantically equivalent - which they never are. They might be superficially similar, with some translation possible using (e.g.) XSLT. But if, for example, com.google:Person has <DisplayName> and no first/middle/last, and com.facebook:Person has <FirstName>, <MiddleName> and <LastName> (but no display name), then XSLT can only translate one way, and nothing can translate the other way without error. It's nice in theory, but - projecting from my experience which is long and across many industries, but obviously still anecdotal - in practice, the semantic differences always require logic beyond XSLT, and thus the namespaces are only of aesthetic value if any. > It is only valid when it can be interpreted by a receiving program (otherwise it is data, not information) True. How is that different than XML or anything else? The same statement applies to XML, namespaces or not. If the program doesn't know what it is interpreting, the namespaces do not matter. If it does know, they don't matter either. Sure, it's a way to mark the source through _all_ elements, but since the program must be aware anyway, you can just as well enclose your Person object with {Facebook: {first:'John', last:'Smith'}} or {Google: {display:'John Smith'}}. Yes, XML has a standard way of doing that - but in practice my experience that it costs about 1000 times what it provides. > With versioning, I meant schema versioning. Admittedly, not a great solution, but at least it allows a receiving party to know which parts can safely be interpreted. And what if semantically, the parts you don't know about make interpretation moot? Practically, if it's a version you don't know, you shouldn't try to interpret it. And that's achieved by a simple 'version' field in JSON. The standard way of doing this buys practically nothing - 99% of XML files out there do not declare or properly follow a DTD. [0] http://www.xach.com/naggum/articles/3224504693262432@naggum.net.html http://www.xach.com/naggum/articles/3224504693262432@naggum.... [1] http://www.schnada.de/grapt/eriknaggum-xmlrant.html http://www.schnada.de/grapt/eriknaggum-xmlrant.html
  • edejong 10y ago
    > and have not ONCE had a use for namespaces or multiple DTDs in a single document. I'm actually rather surprised about that. Take an XSLT document and you're bound to use multiple namespaces. Have you never used an editor which provides tab-completion, quick validation and documentation of tags on the fly? The systems I worked with heavily relied on namespaces for validation, exploration, versioning and prevention of naming clashes. These, however, were heavily distributed systems within government organisations. Also, please note I'm talking about namespaces within and outside XML. I'm saying that namespaces are a cheap and easy to implement design rule. Ok, now your references. [0] is actually an argument for namespaces (and XML schema or suchlike). If I understand correctly, he proposes a system which allows you to specify part of an XML document post-hoc (using a namespace which references a schema which is specific to the module-writer). The second one, I must admit that for me it had a low signal-to-noise ratio. The writing seems to refer only to XML and DTD, but nothing about larger ecosystem, which my arguments were about. Anyways, remove all the banter and you're left with a couple of arguments: 1. the syntax is verbose (yes it is, nobody disagrees, not even the designers). 2. there is no macro support (perhaps useful, one could embed an XSLT stylesheet if necessary). I find this a minor point. It would also severely complicate the parsers and make them stateful and memory-bound. 3. binary representation (in line with 1). How many good, portable binary structured editors do you know? How much does the size of an XML document improve with simple compression to binary? (hint, quite a lot). Also, when going to binary, there are many other design choices, such as: should it be possible to memory-map the document so the CPU is not involved? Should pointers be employed so we can skip sections of the document? Should we use names, ids, UUIDs? Do we optimize for processing use, network use, memory use? [1] seems to only argue about network utilization (which, for most applications, is abundant). The rest of the document (I have to admit, I skimmed some parts), appears to be a rant on everything and everyone stupid. The king who shouts: "I am the king!", is no true king. <skipping some parts> > If it does know [the namespaces], they don't matter either. To structure something, we first need to construct, e.g. bring together and later we need to deconstruct. In both cases, it helps to have namespaces because (de)constructing might involve many different distributed parties, with different versions of software. It is my opinion that in truly distributed systems, naming and typing are of utmost importance. It's getting quite late here. Thanks for making me think about this subject again. Sadly I cannot answer all of your points within a reasonable time.