No, it IS bad and the complaint that 'people use it badly' is simply an excuse to cover for its deficiencies. In many ways, its deficiencies (which YAML/JSON do not have) are an incitement to use it badly, but that's far from the only problem with it.
I am not complaining about being forced to use bad schemas in enterprisey situations, either. That is merely the icing on the cake of the badness that is XML.
I am complaining simply because there is not one instance I have ever come across in my entire programming career (12 years now) where XML would have served me better than an alternative (assuming I had a choice). Zero.
For example:
>With XML I can do this:
>
><experience> <title>Manager</title> <company>Veridian Dynamics</company> <description> Responsible for doing all manner of things. </description> </experience>
Yes, you can, but so what? You can do that in YAML and JSON too. Furthermore, your YAML/JSON parser is 10x less complex, faster, less likely to have buffer overflow security issues and less likely to have memory leaks.
Furthermore, while my app that consumes this markup will probably have to treat <experience><title>Manager<company>Veridian</experience> as valid, because consuming badly formed XML is standard and expected (your product manager will probably treat not parsing it as a bug), my app won't EVER have to treat invalid JSON as valid.
>Of course, we could make it suck
Yes, and there's a 90% chance somebody will. Whereas with JSON and YAML the chances of it being made to suck are far lower, because so many of the unnecessary avenues which are used to make XML suck are closed off in YAML.
I don't have to do anything with XML that I don't want to. I don't have to accept XML that doesn't conform to my schema. You're talking web services again and I'm talking about resumes. You're talking general and I'm talking about a specific place, publishing content, where XML shines. See previous comments - I use XML daily in book publishing. It is not anything like what you're making it out to be.
XML is a markup language. JSON is a serialization language. YAML is a serialization language too. I want to semantically mark up my content. And this is very different than application programming with XML.
You want to write a book with Docbook's XML? Better give it exactly what it wants, or it will reject it. It's not SOAP.
The way I see it we actually want to serialize a datastructure. We have many potential use cases not just presentation. If I download a thousand resumes I'm not as interested in viewing them as documents as I am in consuming them as datastructures, doing filtering / machine learning / ranking / ..
The way I look at it this is as much (and probably way more) a platform to write services on top of as it is a another hole to throw resume.xml down. And for that, json is undeniably better suited.
Nobody is trying to convince you to publish books in json.
>I don't have to accept XML that doesn't conform to my schema.
Yes you do, because otherwise people will treat your application as buggy. People have tried doing this with browsers and it never, EVER, ever works. If one app accepts malformed markup, they expect every other one to do it as well and no amount of preaching about the sanctity of well formed markup is going to change their mind.
>You're talking web services again and I'm talking about resumes.
If resumes are going to be done in markup it's so they can be consumed by web services. There is no point in having a machine readable language if it's not going to be read by machines.
>You're talking general and I'm talking about a specific place, publishing content, where XML shines.
I would rather use LaTeX for publishing content. It's complex, but it can handle layout beautifully.
For simple markup, I would rather use markdown. Markdown in YAML would probably be a better solution than docbook, but docbook's the standard now, so not much you can really do about that.
> Yes you do, because otherwise people will treat your application as buggy
You are mistaking HTML/Browser rendering and XML parsing. An application that parses XML for book rendering, or whatever the hell the purpose of the application is, will fail on invalid input, whether it is because of invalid tag nesting or schema invalidity.
That is NORMAL, and you would do the same with JSON, so that's not because of history of HTML and IE/Netscape/whatever that you need to change your mind about XML.
> If resumes are going to be done in markup it's so they can be consumed by web services
So if a web service was to accept a specific type of XML, it would certainly need to be made valid, if a client does not conform why the fuck do you want your service to be permissive? Seriously.
You can make a service that accepts the resume schema directly, or embed it in a CDATA if you want to.
> I would rather use LaTeX for publishing content. It's complex, but it can handle layout beautifully
Talking about apple and oranges. XML and docbook are not the same.
>You are mistaking HTML/Browser rendering and XML parsing.
I am not mistaking, I am comparing.
>An application that parses XML for book rendering, or whatever the hell the purpose of the application is, will fail on invalid input
Which will be treated as a bug if other applications DON'T fail (which some undoubtedly will).
>That is NORMAL, and you would do the same with JSON
In my experience the OPPOSITE is normal. If XML is invalid but still makes sense, you treat it as valid, because if you don't, your competitors will.
If the customer is getting XML from output X and feeding into your app, he doesn't care that output X is outputting invalid XML if your competitors' apps accept it. He'll just treat your app as the broken one, not buy it and move on with his life and you've just lost a sale. I've seen it happen MANY times. This phenomenon does NOT just apply to browsers, it's just more aptly demonstrated with browsers. NOBODY wants a browser that doesn't accept valid HTML. They never did and they never will.
And what's different about web pages to any other kind of XML? There's more of them, that's all, and people want ALL of them to work. Permissiveness in the consumers is inevitable with ANY kind of XML document that becomes popular for exactly the same reason as it is with browsers.
>that's not because of history of HTML and IE/Netscape/whatever that you need to change your mind about XML.
Yes it is because this sort-of-invalid-but-not-quite problem is a unique one to XML. JSON doesn't have it.
>So if a web service was to accept a specific type of XML, it would certainly need to be made valid
If you don't think somebody would throw invalid XML at your app and not expect it to work then you've clearly never worked with XML seriously.
If you think you can just tell the customer to go fuck themselves because the XML they got from another service doesn't validate, see my previous point.
>if a client does not conform why the fuck do you want your service to be permissive? Seriously.
Because it will make your service work where an impermissive one won't, and when your service works and competitors don't, that's called gaining marketshare.
Seriously.
>You can make a service that accepts the resume schema directly, or embed it in a CDATA if you want to.
Or you could just use JSON or YAML.
>Talking about apple and oranges. XML and docbook are not the same.
Yes, you are mistaking it. HTML is "relaxed" about various parsing errors. XML absolutely is not. If the input document so much as has a closing tag missing, parsing will fail, end of story. If it doesn't match your schema, parsing will fail, end of story. I'm not sure why you keep going on about this point. You're woefully misinformed if you think XML parsers accept malformed input.
> Which will be treated as a bug if other applications DON'T fail (which some undoubtedly will).
Are you talking about "my app accepts schema A and another app accepts schema A.1, therefore if I don't accept schema A.1 people will think my app sucks"? I'm not sure why you think this is an XML-specific issue.
Yes apples and oranges. They taste different, because they are.
> In my experience the OPPOSITE is normal. If XML is invalid but still makes sense, you treat it as valid, because if you don't, your competitors will.
If this is a business requirement you would do the same for JSON.
> If you don't think somebody would throw invalid XML at your app and not expect it to work then you've clearly never worked with XML seriously.
Nope, if you have a customer sending you an XML which should validate against a predefined schema, no, hell no.
I've worked for the European office of publications, and the web services were just receiving tons of XML on a daily basis. And you know what, invalid XML were rejected that's as simple as that. If you don't respect the supplied schema, retry when correct.
> docbook IS XML.
Docbook USES XML.
Last but not least, HTML is not XML, HTML is not a subset of XML. Permissiveness has nothing to do with web services acceptance of invalid schemas.
If you call a Google service whether it uses SOAP (so XML) or REST, if the request body is invalid, you'll be rejected either way. The SOAP one won't try to parse more or resolve issues just because it is XML based.
I am not complaining about being forced to use bad schemas in enterprisey situations, either. That is merely the icing on the cake of the badness that is XML.
I am complaining simply because there is not one instance I have ever come across in my entire programming career (12 years now) where XML would have served me better than an alternative (assuming I had a choice). Zero.
For example:
>With XML I can do this: > ><experience> <title>Manager</title> <company>Veridian Dynamics</company> <description> Responsible for doing all manner of things. </description> </experience>
Yes, you can, but so what? You can do that in YAML and JSON too. Furthermore, your YAML/JSON parser is 10x less complex, faster, less likely to have buffer overflow security issues and less likely to have memory leaks.
Furthermore, while my app that consumes this markup will probably have to treat <experience><title>Manager<company>Veridian</experience> as valid, because consuming badly formed XML is standard and expected (your product manager will probably treat not parsing it as a bug), my app won't EVER have to treat invalid JSON as valid.
>Of course, we could make it suck
Yes, and there's a 90% chance somebody will. Whereas with JSON and YAML the chances of it being made to suck are far lower, because so many of the unnecessary avenues which are used to make XML suck are closed off in YAML.