XML fever (2008)
queue.acm.org
queue.acm.org
What we have today is format creation fever. Particularly in configuration languages. Hucon, TOML, YAML, JSON, sort of JSON formats (HJSON or whatever it is).
The problem with XML is that there are a lot of different programming models (streaming, pull, DOM), many schema and validation formats (DTD, XSD, RELAX NG), to the point that most people didn't care and just manually generated some monstrosity surrounded <>'s using printf.
Personally, the way to get value out of using XML today is to find or make a schema in the most restrictive and expressive format possible that's supported by your development environment (RELAX NG or Schematron are the prime contenders), then use it as a safety belt every time you read or write data. The schema helps handle all the nastiness of parsing, which is the real enemy: https://www.usenix.org/system/files/login/articles/login_aug...
Schema like technology are surprisingly hard to implement and very similar to writing a type checker. Most human readable formats do not support any sort of validation and just now we are starting to see the newer formats try to come up with schema specifications (http://json-schema.org/).
I think the problem with XML has little to do with the language but the organizing ivory tower organizations that got carried away with extending it... but at least those extensions/enhancement were extensions and not modifications of the language itself (ie new versions).
An anecdotal observation is newer specifications for languages seem to follow a more open and transparent ala OSS philosophy (ie spec is on github).
[NB I was using Common Lisp and CLOS in the early 1990s]
OTOH you kind of need hashes/maps in the real world (sexprs can provide this by syntax, but not necessarily by agreed-upon function). And Unicode. And standard representations for the base datatypes. But aside from that there's no reason to enter the Sea of Arbitrary Anglebrackets.
I believe Clojure's EDN format offers all of the above https://github.com/edn-format/edn
Well, plists (foo bar baz quux) and alists ((foo . bar) (baz . quux)) or ((foo bar) (baz quux)) have provided good enough functionality for quite a long time.
> And Unicode.
S-expressions can be Unicode: (edelweiß) is a perfectly valid s-expression.
> And standard representations for the base datatypes.
Common Lisp's extensively documented reader algorithm[1] contains standard read forms for symbols, strings, characters lists, integers, rational numbers, floats, complex numbers, pathnames, structs, comments, vectors, arrays, bitfields as well as some miscellaneous other types.
There's no reason that it couldn't be augmented with something like #{} for hashes (although this would require updating the standard: currently, those characters are reserved for the user; maybe #H{} instead?), #D"2015-12-01" for dates, #U"http://www.example.com/" for URLs and so forth.
This:
#{(title "Example Scheme")
(type "object")
(properties #{(first-name #{(type string)})
(last-name ${(type string)})
(age ${(description "Age in years")
(type integer)
(minimum 0)})})
(required #(first-name last-name))}
{
"title": "Example Schema",
"type": "object",
"properties": {
"firstName": {
"type": "string"
},
"lastName": {
"type": "string"
},
"age": {
"description": "Age in years",
"type": "integer",
"minimum": 0
}
},
"required": ["firstName", "lastName"]
}
JSON is fine, but as you point out, things could be better.
You need hashes/maps in programming languages. But you don't really need first class support for them in a serialization format, since if you have a way to specify custom types (which you need to serialize arbitrary, user-defined types), you can serialize maps as lists of pairs with an appropriate type annotation.
Tags-and-attributes are widely understood, and a format which was just tags-and-attributes would be a reasonably good format. XML is far too complex for its purpose.
Most uses of XML in the past and today use just mainly tags and attributes. XML purpose was for an extensible document format not a general purpose programming language, DSL and/or a serialization format. For its original purpose it isn't a terrible format.
Document formats require special handling of space and comments and repeated nodes (see my other comments). Even S-Expressions ignore spaces in general so are probably not a good format for documents.
For example, we store almost all our parameterized test cases in YAML because we can then use these files as inputs to test runners in JS, Python, Go, etc.
It's the good parts : bad parts proportion that tends to ruin things.
For data serialisation it's just insane. The only reason to use XML to serialize your non markup data is that it's a web technology and you have parsers everywhere. Mapping data back and forward between your data structures and the XML representation is a huge pain in the ass, as there's no natural mapping. For some formats like SVG you basically have to keep data as a DOM in your program.
> And while XML is complicated there are far more complicated formats (YAML).
While the Syntax of YAML certainly is more complicated, totally I would say that it's less complicated without all the XPath, Namespaces etc. you additionally need. YAML maps fairly direct to data structures of programs and the complexity is there to get human readability and edit ability. Something XML doesn't have when used for general data.
> TOML
Is basically just a specification of the largely unspecified INI format, which is older than XML. This is just a format for human editable configuration files, for which we have experience that XML really really sucks.
> JSON
Very simple data format that maps directly to data structures of all common programming languages. The fact that JSON beat XML where XML is at home, in the web shows pretty clearly that JSON is the better format for data serialisation.
TL;DR: Use the correct format for the use case. XML is for markup, not serialisation. JSON is for serialisation, YAML is a better readable JSON e.g. if you mainly use the data for debugging, INI(/toml) is for configuration files.
The reason a markup language like XML is actually sort of useful for a configuration is that spacing and comments can be preserved on modification. That is if I modify the XML manually and then modify it with a script (assuming the script is written correctly) I can preserve my formatting and my comments. As far as I understand such is not the case with many formats (I suppose YAML would be the exception albeit I'm not sure if it preserves white space other than the required whitespace).
I have actually had this use come up. I had 20 or so Maven POM files that I had to modify/refactor. It was fairly easy to do because it was XML all while preserving the formatting and comments.
With the exception of massively complex configuration (aka Ansible) I really don't think most users (particularly non-techy) care that XML is slightly more verbose than YAML. Particularly since configuration is not modified that often and again its like HTML (although HTML is a failure technology wise it is ubiquitous).
As for serialization... XML is bad... I can't come up with any devils advocation for that.
What polluted XML the most was simply being overhyped, especially as "human-readable". It's not binary, but it's also not a good front end for any human task. Although it's capable of flexible markup, that makes it an inefficient source format. Even in the case where you have a document to write, it can be more palatable to parse something simpler and convert it, and then apply finishing touches to the XML where the precision works in your favor.
That said, most data is not really a document, but a tiny fragment with relations. Documents only make sense once you have some kind of story to tell.
HTML and XML syntax is similar (because both are descendants of SGML, and XML was informed by -- but also in some respects a reaction against elements of -- HTML), but not the same; they are more members of the same syntax family, in the same way that large numbers of programming languages are members of a syntax family descended from Algol.
All I want to do is parsing a simple data structure.
To be fair I think pretty much any kind of output generated from a UML model typically has serious problems (code, databases schemas, XSDs, documentation).
Any one else remember that?
Still, I often refer to it as XMHell and if you speak it fast enough, only the truly wise will understand and acknowledge it with a smile and a nod.
There is no sane way that you could represent "pages of XML" in "a few lines of JSON". Maybe the point you're trying to make is that you need just a handful of key:value pairs but whatever generates your config sees fit to do incredibly deep nesting...but that would be an issue with your application, not XML.
I think you're wrong, namely because of arrays. Can you tell me how you'd represent [1, 2, 3, 4] in xml?
If you think this example is contrived, please compare the dependency sections of a clojure project.clj vs that of a Java pom.xml
You don't remember the coming-out party for Java?
It's really sad: we could have had Lisp and s-expressions; instead we ended up with Java & XML, and now we have JavaScript and JSON (which go from bad to better in terms of usability, but bad to worse in terms of safety and stability).
(1) RDF uses the XSD types for literals, and (2) you can turn an XML document very directly into an RDF graph with interconnected nodes.
Once you have done that you can go to "plain" RDF with simple production rules instead of insanely complex XSLT. That is, 250 lines of XSLT goes down to 10 lines worth of rules.
You could create multiple views on the same data by just adding some logic to your XSLT or creating a new XSLT
Queries are(or were at least, it's been many years) built in Xquery which is a simple, functional language that I found much easier to grok than SQL.
Since XML is just a tree and both XSLT and Xquery work on the trees quite well, advanced searching, sorting and relationship graphs came almost for free. I would gladly work with that stack, or something like it, again.
You don't see those words together too often.
His understanding of XML was as follows: Put whatever you want between '<' '>'. It certainly beats reading the w3c docs. Needless to say, I rewrote the application from scratch.
Well, in all fairness, somebody with that attitude would give any serialization/data format a bad name. While I am not a fan of XML, you cannot blame that one on it.
I don't think there are any fancy graphical editors as there are for XSDs - but that's probably not a bad thing as I suspect if things are getting so complex that a graphical editor makes sense then you've probably allowed things to get too complex anyway.