Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



>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.

docbook IS XML.


> I am not mistaking, I am comparing.

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.


> I am not mistaking, I am comparing.

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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: