3 ms·

I don't entirely agree, or rather I think we can profitably go further with this. It's possible to be both liberal and rigorous in what you accept. Let me prov

I don't entirely agree, or rather I think we can profitably go further with this. It's possible to be both liberal and rigorous in what you accept. Let me provide a motivating example. Let us say you have a tool which is nominally supposed to accept JSON, but for whatever reason you might expect a lot of format errors in the JSON: comments which aren't legal, trailing or missing commas, an equal sign instead of a colon, unquoted symbols as keys. If you build some kind of shotgun system to try and repair the JSON, you're going to have a bad time. What if, instead, you define a grammar for your liberal superset of JSON? Now there's no ambiguity about what you accept, or what your parser will do with a given string: it's as well-defined as JSON is, it just accepts more formats of the 'same' data. If your system only ever emits strict JSON, well, you've embodied Postel's law: this is liberal in what it accepts and conservative in what it provides. While still losing none of the rigor of accepting well-defined formats.

ectopod 5y ago
So two people do this and, however principled their grammars, they aren't the same. And when two systems disagree on the meaning of something you get bugs and security holes.
- samatman 5y ago
  Well that's the point isn't it. I don't have to care about the second system's grammar, as long as it accepts at least valid JSON, since that's all I ever intend on emitting. Meanwhile, anyone who would like to check whether e.g. a `// comment \n` statement will be accepted by my parser is invited to check the grammar, which will make all such questions perfectly clear.
tomtomtom777 5y ago
The problem arises when other people try to implement a compatible tool. Sure your JSON rules might not be ambiguous, but they are not standard either so every competitor aiming for compatibility will have to adhere to these specific rules. This means that they need to use samatman-JSON and cannot really on JSON libraries for parsing. Or worse, if these tools become popular, we will see "samatman-rules" flags arising in JSON parsing libraries thereby harming the simplicity that made JSON what it is to today. I think that your example illustrates exactly what makes Postel's law harmful. If you accept JSON, stick to the rules.
- sarchertech 5y ago
  That’s the point of only producing valid JSON. Someone who wants to build something compatible on top of your tool only needs to understand valid JSON. If they want to build a drop in replacement for your tool sure they need to understand your grammar. Or assuming open source, include your tool as a dependency and run it through that first.
- AnimalMuppet 5y ago
  > Sure your JSON rules might not be ambiguous, but they are not standard either so every competitor aiming for compatibility will have to adhere to these specific rules. Every competitor aiming for compatibility with exactly the set of garbage JSON you will accept, no more and no less will have to adhere to those specific rules. That's... not an especially worthwhile goal for a competitor. [Edit: Now, if you output something weird, others might have to be compatible. But this was talking about outputting strictly standard JSON.]
  - tomtomtom777 5y ago
    > That's... not an especially worthwhile goal for a competitor. But it is. Because otherwise we're just embracing monopolies. We can't switch to X because it doesn't accept our input as well as the "main" implementation does. You can only beat BIND, or Postfix or Excel if you at least understand what they understand.
derriz 5y ago
The issue is that either your choice of extensions to standard JSON turn out to be useful and used - which causes the value of having a standard to become eroded, or they remain unused - in which case your work to support a bigger/wider format was redundant. Both outcomes are to some degree negative. All the actual JSON extensions you describe are completely reasonable and reflect failings in JSON as a standard but the solution should be for everyone to agree on a JSON v1.1 standard which fixes the failings rather than have every JSON v1.0 tool support their own particular set of extensions, rigorously defined or not.

ectopod 5y ago

So two people do this and, however principled their grammars, they aren't the same. And when two systems disagree on the meaning of something you get bugs and security holes.

samatman 5y ago
Well that's the point isn't it. I don't have to care about the second system's grammar, as long as it accepts at least valid JSON, since that's all I ever intend on emitting. Meanwhile, anyone who would like to check whether e.g. a `// comment \n` statement will be accepted by my parser is invited to check the grammar, which will make all such questions perfectly clear.

tomtomtom777 5y ago

The problem arises when other people try to implement a compatible tool. Sure your JSON rules might not be ambiguous, but they are not standard either so every competitor aiming for compatibility will have to adhere to these specific rules. This means that they need to use samatman-JSON and cannot really on JSON libraries for parsing. Or worse, if these tools become popular, we will see "samatman-rules" flags arising in JSON parsing libraries thereby harming the simplicity that made JSON what it is to today. I think that your example illustrates exactly what makes Postel's law harmful. If you accept JSON, stick to the rules.

sarchertech 5y ago
That’s the point of only producing valid JSON. Someone who wants to build something compatible on top of your tool only needs to understand valid JSON. If they want to build a drop in replacement for your tool sure they need to understand your grammar. Or assuming open source, include your tool as a dependency and run it through that first.
AnimalMuppet 5y ago
> Sure your JSON rules might not be ambiguous, but they are not standard either so every competitor aiming for compatibility will have to adhere to these specific rules. Every competitor aiming for compatibility with exactly the set of garbage JSON you will accept, no more and no less will have to adhere to those specific rules. That's... not an especially worthwhile goal for a competitor. [Edit: Now, if you output something weird, others might have to be compatible. But this was talking about outputting strictly standard JSON.]
- tomtomtom777 5y ago
  > That's... not an especially worthwhile goal for a competitor. But it is. Because otherwise we're just embracing monopolies. We can't switch to X because it doesn't accept our input as well as the "main" implementation does. You can only beat BIND, or Postfix or Excel if you at least understand what they understand.

derriz 5y ago

The issue is that either your choice of extensions to standard JSON turn out to be useful and used - which causes the value of having a standard to become eroded, or they remain unused - in which case your work to support a bigger/wider format was redundant. Both outcomes are to some degree negative. All the actual JSON extensions you describe are completely reasonable and reflect failings in JSON as a standard but the solution should be for everyone to agree on a JSON v1.1 standard which fixes the failings rather than have every JSON v1.0 tool support their own particular set of extensions, rigorously defined or not.