Too strict, too loose

Some spec's are marvelously defined - neither too strict, nor too loose : not sure how they do it : it has just the right amount of abstractions and constraints. Same with some well designed api's.
A common way to identify this would be if both the power user and a novice can both work well with it.

But from what I see, they are a rare breed.
From a spec point of view (which is what triggered this post), when it is too strict - it cripples innovation and does not allow easy extensions to the base specs. If they are too loose, all sort of interpretations come into play which are not consistent with why it was designed that way: leading to potential for abuse, fragile implementations and lack of adequate interoperability (except maybe for the very basic feature set).
Premature assumptions in a spec lead to long term heartburn ... especially after a spec gets widely implemented/deployed : changing anything significant will meet with too much resistance !

Relying on 'common practices' and 'usual way to use' are great way for others to start and are very useful in the short term, but IMO if expectation of how an implementations work is based on these - then it can & will lead to fragility.


This post is targetted at a specific set of observations I have been making in past few weeks and the insights I learned from them : and no, I am not going to specify exactly what they are :-)