3 ms·

> - JSON doesn't have namespaces, making integration of different data-sources quite hard. The only reason anyone would ever say that is ... that they have use

by beagle3 10y ago

> - JSON doesn't have namespaces, making integration of different data-sources quite hard. The only reason anyone would ever say that is ... that they have used XML (or SGML) and are subscribed to that mindset. Every toplevel JSON document is a valid value in any other JSON document. That's how easy it is to integrate. The only reason that XML/SGML needs namespaces in the first place is that the schema dictates what an element, e.g. <block>, can have as children or attributes, and how many -- and as a result, <block><statement/></block> from a programming language and <block><cityblock/></block> from a city design schema cannot be mixed (neither would be valid in the other's schema). So you have to use <code:block><code:statement/></code:block> and <city:block><city:cityblock/></city:block> to differentiate them. > - XML allows me to do versioning within documents. What kind of versioning are you referring to? Schema versioning? Data versioning?

edejong 10y ago
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 large). However, I do subscribe to namespaces, since it allows global referencing of names. I also do subscribe to formal grammars, mature standards, and good documentation. FYI, I've designed streaming JSON based secure messaging systems, did binary-only schema's for speed, and for simple tasks I just implement JSON+REST, since everyone nowadays come to expect it. It's just that I think XML got an undeserved bad reputation and many of the 'good parts' have been forgotten. With regard to namespaces, when designing standards, it is very useful to separate one 'person' definition from another, since they might not have the same semantics. 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. I don't really subscribe to the 'it is a valid value in another JSON document'. It is only valid when it can be interpreted by a receiving program (otherwise it is data, not information). The namespaces are not there for validation (alone), they are there for interpretation. 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.
- 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

by beagle3 10y ago

edejong 10y ago

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 large). However, I do subscribe to namespaces, since it allows global referencing of names. I also do subscribe to formal grammars, mature standards, and good documentation. FYI, I've designed streaming JSON based secure messaging systems, did binary-only schema's for speed, and for simple tasks I just implement JSON+REST, since everyone nowadays come to expect it. It's just that I think XML got an undeserved bad reputation and many of the 'good parts' have been forgotten. With regard to namespaces, when designing standards, it is very useful to separate one 'person' definition from another, since they might not have the same semantics. 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. I don't really subscribe to the 'it is a valid value in another JSON document'. It is only valid when it can be interpreted by a receiving program (otherwise it is data, not information). The namespaces are not there for validation (alone), they are there for interpretation. 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.

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