4 ms·

> So now you turn one problem into two problems: manage the schemas and manage the data This seems to completely ignore the fact that we are already managing s

by epr 7y ago

> So now you turn one problem into two problems: manage the schemas and manage the data This seems to completely ignore the fact that we are already managing schemas right now in the form of ad-hoc parsers and serializers which are arguably much worse than a more formally specified alternative.

pjc50 7y ago
The HTML vs XHTML situation: would you prefer a hard failure on any error, or a graceful degradation system that is therefore always slightly degraded? We go back and forth on this because tightening the schema only works when you can adequately define the requirements of both ends up front, and there isn't a vendor battleground happening in your standard. Developers end up escaping into an unstructured-but-working zone. Classics like "it's such a hassle to get the DBA to add columns, so we'll add a single text column and keep all the data in there as JSON".
- epr 7y ago
  > tightening the schema only works when you can adequately define the requirements of both ends up front There are degrees of tightening though, aren't there? It would be a matter of necessity (to me, at least) that an interface like he describes be extensible. To me, it's about better OS primitives with more guarantees, etc. Versioned APIs with options to fallback to older versions (to at least some extent) seems like an obvious outcome. The last thing anyone would want would be the equivalent of JSON in a database column, which would completely defeat the purpose.
- pdimitar 7y ago
  > The HTML vs XHTML situation: would you prefer a hard failure on any error, or a graceful degradation system that is therefore always slightly degraded? Definitely would prefer the hard failure. The community will literally fix all of that in a week -- all template engines and DOM generators will adapt to avoid the hard errors and everything has a good shot at becoming better as a result.

by epr 7y ago

pjc50 7y ago

The HTML vs XHTML situation: would you prefer a hard failure on any error, or a graceful degradation system that is therefore always slightly degraded? We go back and forth on this because tightening the schema only works when you can adequately define the requirements of both ends up front, and there isn't a vendor battleground happening in your standard. Developers end up escaping into an unstructured-but-working zone. Classics like "it's such a hassle to get the DBA to add columns, so we'll add a single text column and keep all the data in there as JSON".

epr 7y ago
> tightening the schema only works when you can adequately define the requirements of both ends up front There are degrees of tightening though, aren't there? It would be a matter of necessity (to me, at least) that an interface like he describes be extensible. To me, it's about better OS primitives with more guarantees, etc. Versioned APIs with options to fallback to older versions (to at least some extent) seems like an obvious outcome. The last thing anyone would want would be the equivalent of JSON in a database column, which would completely defeat the purpose.
pdimitar 7y ago
> The HTML vs XHTML situation: would you prefer a hard failure on any error, or a graceful degradation system that is therefore always slightly degraded? Definitely would prefer the hard failure. The community will literally fix all of that in a week -- all template engines and DOM generators will adapt to avoid the hard errors and everything has a good shot at becoming better as a result.