| > Except its pretty common now for programming languages add quality of life changes that loosen some of the strict parsing rules, such as trailing commas or optional semi colons. Same with whitespace, many languages don't pay much attention to it then you have a formatter that is strict about it (gofmt). This is Postels law in action, liberal acceptance strict output. Erm ... no, it's obviously not? Or at least not in a way that is relevant to this discussion. I am obviously not objecting to specifying languages that give you a lot of freedom in how you format things, so what is the point of bringing up that you could interpret the robustness principle to mean just that? I am obviously objecting to accepting input that does not conform to the respective relevant specification, and the fact that making languages more flexible in their formatting is often useful has no relevance to that whatsoever. You interpret some term to mean a broad range of things, I point out that one of those things is a bad idea, and your defense is that one of the other things is good ... how is that even an argument? How does that change that what I pointed out is a bad idea? > The alternative is strict adherence to whitespace then no need for a formatter, just have the compiler reject it and put the burden on the programmer. No, the alternative is strict adherence to the language specification. Or, really, it's not an alternative at all, because there is zero contradiction between specifying a language with flexible whitespace grammar (or separator grammar or whatever) and then strictly enforcing that grammar (and thus obviously avoiding interoperability problems). > Again your opinion is not shared historically, ECN is held up as an example of the robustness principle having been followed in most stacks, with some problem ones that did not causing some issues [1]. In other words: You position is unfalsifiable? If there are no interoperability problems due to everyone interpreting messages identically, then that is obviously due to the robustness principle, and if there are interoperability problems because implementations deviate in how they interpret messages, then that is also obviously a success of the robustness principle? Is there any scenario where that robustness principle would not count as successful? > Then your points are just irrelevant? We can play this game forever. Just the fact the you are using HTML and not XHTML and TCP under that to write these should make some relevant point that you can't seem to see. How is the fact that I am using something in any way relevant to the question of whether an alternative would have avoided interoperability problems and vulnerabilities? > Or more likely all these developers weren't incompetent including myself, just when given the choice the strictness of XHTML lost to the liberalness of HTML proving Postels law again. Messy and robust won over clean and fragile again, that's the point, get it? How is it relevant that HTML won? How do you connect from "technology X won over technology Y" to "therefore, technology Y would not have had fewer interoperability problems and vulnerabilities than technology X"? Why do you answer every question as to technical properties of a technology with "it lost" or "it won" while completely failing to say anything at all about the technical property being discussed? NOONE DENIES THAT HTML WON OVER XHTML. Also, it seems you almost completely ignored the central explanation of my previous post, simply to repeat your previous points as if I never had said anything. I am happy to read your explanation as to where my analysis is wrong, but I am completely uninterested in reading over and over points that I repeatedly explained why I don't agree with them with no insight at all into how my reasoning is wrong. |