There are two quite
different issues?
What is the best size and
layering etc for a standard technology; and what is the
best for the standard document? (People all the time
conflate the technology with the document IMHO.)
(But you would expect the
size of the standard document would to some extent need
to reflect the size of the techology. )
But apart from that
everything will have its own rules: looking for general
principles is well and fine as long as the abstraction
doesnt then become unprovable dogma that prevents
advance.
Actually i think xml/xpath
might be quite rare in having the standards document
lead the technology, rather than being a QA on the
technology being pushed or instigated by vendors and
dictators-for-life.
I dont think it is
necessarily a bad thing if a standard has known gaps or
clear limitations or TBDs. Should ODF have been held up
until it had a spreadsheet formula language? Of course
not.
But if a formal standard
process is above all a QA on the documentation for a
technology, what it would bring to JSON is not
necessarily fixes for the edge-case problems, or the
addition of comments, even though committees love
tinkering, but we might expect it should be a clearer
list of those edgecases and short comings, and standard
ways to ameliorate them.
Regards
Rick
