The fact that a solution is treading familiar ground does not invalidate its utility.
In addition, arrays must be indicated clearly in JSON while you can consider children of an xml nodes to always form a list (be it empty or containing one element).
So while the two format are very similar, there is still some differences that doesn’t make them interchangeable for every usecase.
If there had been an opinionated SGML syntax which mapped directly and unambiguously to common language primitives and back, I'm sure it would have been more popular than JSON.
Though it seems like XSLT should support JSON:
As a simple example, there's no technical reason why XPath couldn't allow you to either use namespaces as written in the document[1] or ignore them when appropriate[2]. Nobody cared about usability and it's the number one reason I've heard why developers with jobs to do fled to JSON / YAML as quickly as possible. A similar story arises with XPath 2 — libxml2 never got support so that standard effectively doesn't exist for most projects, but there's no way to shift the resources away from developing further revisions which will also not be widely used towards much cheaper basic investment in shared infrastructure.
1. e.g. if the doc is <foo:bar>, it should never require you to write {http://path/to/foo}bar to match that element.
2. Ever try to target docs in multiple versions of a standard?
I don’t like js/json at all, but for json (and without much js knowledge) I can roll out simple validation in less time than is needed to understand these schema formats. If my structure is dynamic, omg it will be hard to explain it to declarative validator. If it contains value-level type logic (graphs, references), I bet second phase of validation by hand is inevitable anyway.
A second thing, full-blown xml is alien to any structures of simple languages and cannot be serialized like jsonlib.encode(foo). You create nodes, set attributes, build trees, all that mess. It feels like using a 17th century official mail ceremony to send “)))” to your buddy.
Huh? Could have fooled me. In Cocoa, for example, serializing to JSON and serializing to an XML property list (or binary property list) is effectively the same code.
https://developer.apple.com/documentation/foundation/nsjsons...
https://developer.apple.com/documentation/foundation/nsprope...
And of course that is why some of the XML tools are so heavy: they deal with the full meta-format. The "nice" thing about JSON is that it doesn't have this indirection step, it's just one concrete language, and that's why it is simple. But again, it's trivially easy to define an actual concrete markup language using XML that is just as simple.
I agree with you that the choice of <key>theKey</theKey><string>value</string> rather than <theKey>value</theKey> was regrettable, had I designed the format I would have chosen differently. I think they wanted one DTD to describe this format, which wouldn't have been possible without keeping the meta-level indirection.
I created XML-based archivers for Cocoa that don't have this problem[2]. Again, this wasn't hard, and the API is NSKeyedArchiver compatible, so [MPWXMLArchiver archivedDataWithRootObject:someObject]; gets you a nice XML representation.
[1] http://www.xml.com/pub/a/98/10/guide0.html?page=2
[2] https://github.com/mpw/Objective-XML/blob/master/MPWXmlArchi...
DTD was considered obsolete more than a decade ago.
Nobody uses anything but XSD nowadays.
see also: hating pascal's 'end' instead of '}' or claims that python is readable because it doesn't even have '}'
People shouldn't use JSON for anything hand-written. YAML or even the older INI format are way better suited for configuration files for one reason alone: they allow comments.
NIH claim is probably valid when there are no noticeable difference. In my opinion, XML differs a lot from JSON, particularly when one need to write snippets by hand. JSON also seems more logical/laconic (once upon a time M-expressions were supposed to come to stage, but S-expressions turned up to be good enough).
Partially yes, but it's also at least in part due to a "fuck all this language theory crap, lets just standardize something already" approach.
(Fair discloure: I'm a jq maintainer.)
Why do you need comments in a structure of nested - unique key mappings - arrays - strings - numbers - booleans - nulls ? You can include comments, just like any string, into it, just reserve a key with unique name, if you want. From JSON parser/transformer point of view, "comment" as a concept isn't a data structure piece, it's rather "intent" piece.
The "Web scale" is what MongoDB tried to sell (unfortunately, successfully), and it's not even close to being web scale.
Neither JSON schema or XML schema are particularly popular - and for good reason. Let's say you want to create a schema that limits field "country" to be limited to ISO 3166-1 country codes - either you:
* Keep that schema file updated by hand every time something like Sudan breaking in two happens (no).
* Write a program that generates the schema (seriously... no)
* Do schema validation in code where it belongs - pulling in relevant validation data from canonical sources, rather than some markup language invented by people who didn't have the imagination to consider a really common use case.
Anyway, code:
yaml_text:
John: Yemen
James: South Sudan
from strictyaml import load, MapPattern, Str, Enum
import pycountry
result = load(
yaml_text,
MapPattern(
Str(),
Enum([country.name for country in pycountry.countries]),
)
)
Python isn’t a good choice there, as it is too flexible. For example, that code could have gotten the list of allowed country names from a file, database, or URL.
⇒ If I have to send such json to you, I almost would have to write my program in python, and even then, it could be hard for me to replicate your setup.
That is exactly the point. You should be able to do that, because the canonical list of data could easily from any of those and it should the up to programmer's discretion how to fetch it.
The point of validation is to prevent invalid data from slipping through a net at minimum cost and that's how you do that.
Suden, Sudaan and South Sudan were all invalid countries in 2010 and that YAML was invalid. In 2012, Suden and Sudaan were invalid but South Sudan was not so that YAML was valid.
In the above example you have to make no code changes in order to account for that - just update pycountry every so often.
With XML schemas and DTDs either you don't validate country at all (letting Suden and Sudaan) through the net. Or, you rewrite and redistribute the schema by hand every time some dependency like a list of countries changes.
>If I have to send such json to you, I almost would have to write my program in python
Only if I choose to validate that data using a shared schema. Frankly, I've dealt with XML a lot and the number of times I've been handed a shared schema of any kind is very low. People just don't seem to use them. If they define an API in XML for instance they tend to just send examples and give a written explanation (e.g. insert valid country name here).
I don't see much value in making a schema more inherently "shareable" especially not if it means it has to be re-released every month.
There is a lot of use for libraries dealing with time and dates. When you want to cover all cases, at some point you get to the situation when you have to allow variable number of seconds in a minute - not always 60, but sometimes 59 or 61, or may be even different numbers. And you don't know in advance - for arbitrary long future - which minutes will have which number of seconds.
So, for your timekeeping system to maintain precision, you have to allow external updates for when a minute will be considered non-60 seconds.
And those cases could happen more often than changing a list of valid country codes.
What would you do with time then?
I wrote some example code below that shows how you can validate with list of countries in such a way that no code changes will be required when the list changes.
To your other point, however, dynamic code generation is becoming much more common. AWS generates a huge amount of its code from JSON definitions across multiple languages to keep its SDKs up to date. I could see schema validation being valuable in this domain as well.
There is. I find examples - snippets of XML/JSON - to be the best way of communicating this - not schema languages.