4 ms·

Sorry to rain on yours, but XML isn't bad. The way people used it is bad. Just because you were forced to use bad schemas in enterprisey situations doesn't me

by bphogan 12y ago

Sorry to rain on yours, but XML isn't bad. The way people used it is bad. Just because you were forced to use bad schemas in enterprisey situations doesn't mean XML is bad. SOAP is not XML. Spring MVC is not XML. Those things use XML. Docbook's pretty easy to follow. That, in my opinion, is a great example of XML+XSLT. With XML I can do this: <experience> <title>Manager</title> <company>Veridian Dynamics</company> <description> Responsible for doing all manner of things. </description> </experience> It describes exactly what we're looking for in the same way as the JSON variant does. My editor will auto-close those tags the same way my editor will auto-close the closing curly braces in the JSON version. Of course, we could make it suck if we just go ahead and add all sorts of extra rules and hierarchy and turn it into a monstrosity. But I'd rather not.

crdoconnor 12y ago
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.
- bphogan 12y ago
  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.
  - crdoconnor 12y ago
    >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. Docbook is complex and it can't: http://www.docbook.org/tdg/en/html/part2.html http://www.docbook.org/tdg/en/html/part2.html 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.
    - flaie 12y ago
      Hard to not see you're way too stubborn. > 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.

by bphogan 12y ago

crdoconnor 12y ago

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.

bphogan 12y ago
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.
- crdoconnor 12y ago
  >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. Docbook is complex and it can't: http://www.docbook.org/tdg/en/html/part2.html http://www.docbook.org/tdg/en/html/part2.html 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.
  - flaie 12y ago
    Hard to not see you're way too stubborn. > 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.