4 ms·

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

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.

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.