Re: What's wrong with GEDCOM ?

You pretty much said it David - thanks!

The standards designed/specified by big committees full of big-wig vendors
who have vested interests they want to protect, and "edges" over other
vendors that they want to enhance, tend to be a disaster as the resulting
spec is too vague. My issue with the ANSI C spec, for instance, was that it
left so much "undefined" or "unspecified" that you could drive a bus through
all the holes. As a consequence, C is not the portable language that it was
hoped to be.

Smaller, more focused, committees tend to define cleaner standards. However,
rather than being an "ivory tower", they would nowadays put out RFIs to
gather requirements, and have peer reviews for the drafts. There's a subtle
difference is considering lots of valid inputs, and having the specification
actually defined by a large number of subjective people.

Tony Proctor

"David Harper" <devnull@xxxxxxxxxxxxxxxxxxx> wrote in message
news:0Oa%i.16594$ib1.15815@xxxxxxxxxxxxxxxxxxxxxxx
singhals wrote:
Tony Proctor wrote:
[snip]

The older ANSI C and ANSI SQL specs are abomininations resulting from a
design-by-committee approach. You can understand the approach taken
with
Java whereby it was designed and evolved as a proprietary standard
before
being considered for an international standard.


Remind me again please -- what makes _their_ design-by-committee results
worse than what _your_ project committee could come up with?

If standards in the genealogical software community need to be
agreed-upon rather than forced-upon, you're going to get
designed-by-committee standards.

If it's bad when I (or Bob V) do it, then it's bad when you do it.
Ancient adage roughly translated as sauce for the gander.

I guess what Tony is trying to say is that large committees tend to have
a wide range of conflicting (and often irreconcilable) goals. In the
context of committees whose remit is to design some kind of standard,
the result is a standard that is bloated, confusing and often impossible
to implement effectively.

The best standards seem to come from very small committees, or better
still, two or three very talented and highly-focussed individuals. Look
at the standards which underpin the Internet -- IP, TCP, SMTP, HTTP --
which each originated as the work of one or two people. Likewise,
languages such as C and Fortran, which were created by one person and a
team of half a dozen, respectively. (And John Backus's Fortran team not
only specified the language, but implemented the world's first
optimizing compiler on a computer which had less memory than your
cellphone!)

David Harper
Cambridge, England


.

Relevant Pages

  • Re: C++ and Middleware
    ... C++/CLI is largely a Microsoft initiative and is being standardised by ... a committee within ECMA, not the ISO and ANSI committees ... that produce C++ standards (JTC1/SC22/WG21 and INCITS J16 ... Some members of the latter committees have been able ...
    (comp.lang.cpp)
  • Re: [9fans] Brdline
    ... standards czar, your brilliant expert, with a background in law and social science as well as technology, who is able to apply duly constituted public authority to a standard. ... My last employer killed my sense of worth by pilling me on standards committees, evaluation committees, coffee-cup-washing committees ad infinitum. ... I may not be a brilliant expert, but they put me there as an expert, and killed the expertise simultaneously. ...
    (comp.os.plan9)
  • Re: Who uses clapack?
    ... > Tell ISO to change their rules. ... > so unused standards are automatically withdrawn. ... I recall ANSI X3J sending a letter to all its committees ... cycle on revisions. ...
    (sci.math.num-analysis)
  • Re: A question about graphic I/O
    ... Is it the reluctance of vendors who sit at standards ... >committees and have competing products? ... the errors themselves, i.e., the goofs that we Fortran users are ... We can make errors on any platform. ...
    (comp.lang.fortran)
Loading