7 ms·
The reinvention of XML in JSON is almost complete - JMESPath vs XPath, JSON Schema vs XML Schema etc. If you need semi structured data to that level, consider u
by xchaotic 9y ago
The reinvention of XML in JSON is almost complete - JMESPath vs XPath, JSON Schema vs XML Schema etc. If you need semi structured data to that level, consider using XML instead - you can validate it, there's plenty of tools, it's very stable and mature etc
- zoul 9y agoIs that a bad thing? For cases where the document is at least partially written by hand it makes sense to replace XML with something more friendly, such as JSON or YAML.
- foepys 9y agoWasn't the basic idea of JSON to be small and unstructured to be sent between applications? Shoehorning everything into JSON that is already solved by XML seems illogical, as GP already said. It reeks of NIH. 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.
- nine_k 9y agoSmall, or smaller than XML, yes. Unstructured — why?
- avmich 9y agoTo me, JSON can be viewed as slightly enhanced S-expressions, enhanced in a particular way. It would sound strange hearing "shoehorning everything into S-expressions in Lisp that is already solved by structural Fortran syntax seems illogical". 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).
- bufferoverflow 9y agoWe still need XSLT for JSON to complete the circle. Though it seems like XSLT should support JSON: https://www.w3.org/TR/xslt-30/#json https://www.w3.org/TR/xslt-30/#json
- coding123 9y agoI thought JavaScript was the xslt of json.
- c-smile 9y agoThere are plenty transformers already, for example: http://goessner.net/articles/jsont/ http://goessner.net/articles/jsont/
- avmich 9y agoXML Stylesheet Transformation, the language to describe transformations of XML documents into another XML documents. Isn't jq or JMESPath an example of such a language for transformations?
- bshacklett 9y agoNo, those are query languages akin to XPath.
- avmich 9y agoWhat's the difference between query and transformation then? Isn't transformation a (vector) function ^f of input ^x, with n dimensions of x and m dimensions of f where f_i = f_i(x_1, ... x_n)?
- Thiez 9y agoXPath can be used in Xslt, but not the other way round. In Xslt you can create new elements, while in XPath you can't. Seems like a pretty big difference to me. XPath isn't Turing complete either, while Xslt is.
- 9y ago
- btown 9y agoBut can you store XML in a database that is Web Scale?? /s
- edraferi 9y agoMarklogic.... sort of.
- dmitriid 9y agoYes. It's one of the many abilities a database like PostgreSQL has. The "Web scale" is what MongoDB tried to sell (unfortunately, successfully), and it's not even close to being web scale.
- lrem 9y agoSQLite will happily store whatever you throw at it and scales perfectly to my Web Site ;)
- hliyan 9y agoIsn't that what we want? I would think that solving the same problems for a less verbose format is a good thing. And looking at the examples and the library support (http://jmespath.org/libraries.html http://jmespath.org/libraries.html) I would say this solves a real problem. I can already think of several use cases for my own system. The fact that a solution is treading familiar ground does not invalidate its utility.
- Finnucane 9y agoIt's not very much less verbose, really. You still need a key and a value. The only thing you lose, really, is the end tag. For a complex text document in say TEI or Docbook, I don't see how this is much of an advantage.
- humanrebar 9y agoIt's less complex since there aren't attributes. Of course, if you like attributes, then that's a downside.
- Finnucane 9y agoYou could have attributes, they just need to be another nested object. This makes a mess, though.
- titanix2 9y agoNo, you also loose the attribute system and thus the ability extend existing elements without changing their structure. 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.
- jelder 9y agoThe reason I prefer JSON over XML is the latter's ambiguity. It's completely obvious how to convert a native object into a JSON object, for example. The translation to XML brings all sorts of questions about when to use tags vs. attributes of tags. It's cognitive load I'd rather spend on solving the problem at hand, not serialization. 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.
- crdoconnor 9y agoThe "reinvention" is not complete and will never be necessary. The difference is that XPath is necessary to query XML because it's a botched horribly overcomplicated, designed-by-committee markup language. Except for tools like jq no such language is actually required for JSON because it maps on to language structures that always exist. 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.
- benjaminjackman 9y agoThat ability to use outside canonical sources is really interesting. Are there some existing examples of schema languages with that feature?
- crdoconnor 9y agoThe point I was making was that you shouldn't use a "special" language for validation at all - you should just use a library in a regular language to do it. Anyway, code: yaml_text: John: Yemen James: South Sudan python code: from strictyaml import load, MapPattern, Str, Enum import pycountry result = load( yaml_text, MapPattern( Str(), Enum([country.name for country in pycountry.countries]), ) ) full disclosure: I wrote the validation library ^^
- Someone 9y agoThe idea behind XML schema, DTD, etc. is to pick a simple language to express schemas in, so that implementations in different languages have a decent chance of being compatible with each other. 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.
- paulddraper 9y agoWe can create first-class arrays in JSON.
- maxxxxx 9y agoThat's the only advantage I see in JSON but it's a good one.
- booleandilemma 9y agoJSON still doesn’t support comments though, they need to work on that.
- avmich 9y agoTo me this sounds almost like "S-expressions still don't support comments". 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.
- k6k7f7uky8ki 9y agoSomething seems odd about wanting to put comments inside the JSON instead of before it. Then people will want a way to read the comments programmatically, then they'll want annotations, etc.
- a-saleh 9y agoHm. One reason why I prefer Json to XML (and I actually like XML) is, that JSON is simpler. The fact that XML has schema definitions out of the box, and that these schema definitions can reference other definitions would lead to more complex parsers that can contain more bugs and vulnerabilities.
- blattimwind 9y ago> would lead to more complex parsers that can contain more bugs and vulnerabilities. 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.
- wruza 9y agoLast time I checked, XML was uncertain which validation should I use. DTD, Schema, other solutions. Each has syntax/structure and 1st page explanation so cryptic, that I don’t even understand where do I begin. 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.
- mpweiher 9y ago> and cannot be serialized like jsonlib.encode(foo) 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/nsjsonserialization?language=objc https://developer.apple.com/documentation/foundation/nsjsons... https://developer.apple.com/documentation/foundation/nspropertylistserialization?language=objc https://developer.apple.com/documentation/foundation/nsprope...
- wruza 9y agoYes, but property list is a subset of XML and Cocoa’s almost internal format. It doesn’t even connect keys to values, probably losing all the xpath/xslt/etc abilities. No custom schema too?
- mpweiher 9y agoHmm...since XML is a meta-language describing a family of markup language[1], every actual XML-based language will be a "subset". 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 http://www.xml.com/pub/a/98/10/guide0.html?page=2 [2] https://github.com/mpw/Objective-XML/blob/master/MPWXmlArchiver.h https://github.com/mpw/Objective-XML/blob/master/MPWXmlArchi...
- Avshalom 9y agoPeople become just furious at the existence (especially when they never write xml by hand) of closing tags. Because the XML people wanted to be able to spot unclosed elements before they reached EOF and because they thought it would be nice to be able to report what was actually unclosed we're going to have to just accept a world in which programmers will use absolutely anything before using xml. see also: hating pascal's 'end' instead of '}' or claims that python is readable because it doesn't even have '}'
- acdha 9y agoThe problem with XML is that almost every tool has bad usability — both things like basic tasks frequently dumping you into a thicket of cryptic standards docs or that the libraries in most common languages have unnatural API choices (i.e. they follow the libxml2 C interfaces) and leave a lot of basic usability on the floor. 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 http://path/to/foo}bar to match that element. 2. Ever try to target docs in multiple versions of a standard?
- deleted 9y ago[deleted]
- drderidder 9y agoYou miss an important point, JSON is a subset of valid parseable JavaScript. This is a huge win when working with the web stack.
- cryptonector 9y agojq is a better XPath/XSLT. It's been for a long time now. (Fair discloure: I'm a jq maintainer.)
- intrasight 9y agoExactly. I'll stick with XML, XPATH, and XSLT - thank you very much. Is standards-based, natively-implemented, and super-fast. If a web services sends me JSON, the first thing I do is serialize it to XML.