"No connection between RDF and XML" is definitely not true.
(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.
JSON is the least-bad solution in the present day, but it's not a good format in itself. It's excessively verbose, overloads symbols and strings and cannot map general objects to values.
"one of the most troubling XML problems that is often experienced when encountering schemas generated from UML models"
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).
Now in 2015 we have XML prejudice and aversion where people trash XML as the worse possible format. As with many things it has its strength and weaknesses a couple of them being that a parser exists for almost all programming languages and the syntax of XML is probably the most widely understood (given so many people know HTML). And while XML is complicated there are far more complicated formats (YAML).
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...
I agree but XML the language with out namespaces or schemas is still useful.
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).
It really is appalling how many man-millennia have been spent reimplementing an already-realised ideal. Imagine how much better the world would be if we had settled on Lisp or Smalltalk plus s-expressions back in the early 90s!
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.
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.
> OTOH you kind of need hashes/maps in the real world
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.
> OTOH you kind of need hashes/maps in the real world
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.
I don't think the syntax of XML is widely understood. How many people really know the syntax of DTDs, processing instructions, entity references, namespaces, CDATA sections, and so on?
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.
I'm almost positive we have worked together (your handle stuck out... percussion?)... I agree the extension/validation parts of XML are not well understood (DTD, entity references, namespaces) but in general rarely used or needed.
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.
Please don't trash YAML. If you stick to "the good parts", YAML is an almost perfect human/machine readable and editable text format.
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.
I didn't mean for that to be an interpretation of trashing YAML. The YAML format is more complex to parse and there are less parsers available. It is an easier to read format for sure but that comes at a cost. There are lots of good things about YAML.
It's just because XML is a bad choice. It's a standard for creating markup languages, but use in HTML failed because it's more verbose and doesn't cope at all with user errors.
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.
While I think we are on the same page (I did say XML has strength and weaknesses) I think XML is undervalued for a configuration language particularly if the configuration language is to be modified by another application or script.
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.
At the core of XML you can still see the SGML origins. It is great stuff if you have an actual document to work on - like, documentation, or an essay, or a manual... there are some very comprehensive schemas and renderers around for those use cases, that can do heavy lifting where Markdown or Word start failing you, and TeX is inappropriate.
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.
> the syntax of XML is probably the most widely understood (given so many people know HTML).
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.
xml is so complex and poorly understood, even big companies like google and facebook have failed to implement xml parsing securely, see xxe attacks. If you didn't know it's possible to configure the xml parser insecurely you might be affected, especially if you're using java. xml specifies how to load files from disk while parsing and validation can trigger GET requests to firewalled systems.
All I want to do is parsing a simple data structure.
I inherited an application from a person who was apparently taken with XML. The app's data and output was kept in his own home-brewed XML format with hand written output and parser functions.
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.
> His understanding of XML was as follows: Put whatever you want between '<' '>'.
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.
XML can have a defined schema to validate data against. Does JSON have anything similarly defined as part of the language? It seems like an afterthought. Does anyone use it in practice?
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.
I always felt XMLs killer feature is its editor support: auto-completion through XSDs and instant validation. Unless I get that in other formats, I frankly don't care a lot.
I spent several years working with the Marklogic[0] document database before NoSQL was cool and before I had even heard the term. It was incredibly freeing working with arbitrary XML documents and fragments. As a benefit we were able to transform data into HTML markup with a simple XSLT transformation.
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.
I'm sure others who have been around longer remember other examples, but in my life I have never before or since witnessed a media blitz for a "technical" standard as the coming out party for XML in the '90s. Almost overnight the book shelves, magazines (yes those were both things back then), and even TV news proclaimed the dawn of the new age. A wave incoherent mass insanity swept the industry with the promise that this sometimes white space sensitive text data format with all the deliberate under and over specifications that are hallmark traits of design by committee was literally going to solve every problem in software engineering, enterprise IT, and of course investing in the dot com dumpster fire (pre first collapse). The emperor never had any clothes. Disk space, network capacity, cpu time, sanity, dignity - mattered not. No problem could not be solved better with XML. Dissension was heretical.
To this date I feel frustrated when I have to deal with a few pages of XML that could easily be a few lines of json. Then again, enterprises love it, so I can't complain too often or loud.
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.
"a few pages of XML that could easily be a few lines of json"
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.
> … in my life I have never before or since witnessed a media blitz for a "technical" standard as the coming out party for XML in the '90s.
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).
If you're looking to describe document structure in a markup language, especially where mixed content is involved (think think running text, not database results), XML is great.
45 comments
[ 4.2 ms ] story [ 99.2 ms ] thread(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.
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).
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:
seems a lot nicer to my eyes than: [1] http://www.lispworks.com/documentation/lw70/CLHS/Body/02_b.h...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.
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.
http://json-schema.org/
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.
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.
http://www.marklogic.com/
You don't see those words together too often.
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).