[EMAIL PROTECTED] writes:
> Richard Robinson's speculations as to what I might say ran completely
> counter to what I was actually saying. He first said that I would go on to
> explain that open-source was a bad form of development whereas I actually
> said that it was just one of several equally legitimate methods.
> [...]
> It is, because the same applies to a lot of other interested parties who
> either cannot or choose not to take part in an open-source project.
> [...]
> I think she was, in fact, right. Talk of a standard is meaningless because
> nobody has the power to enforce it. Let us talk, instead, of a protocol for
> the exchange of information as I have suggested before. Instead of fighting
> over the points we disagree on, let's start by establishing what we do agree
> on and let's do it on this list, not in secret conclave.
In my opinion, what would be nice to have is
1. a well-defined ABC standard describing a common feature set for `most'
applications. This should include most if not all of what is now
specified in the 1.6 standard (we could leave out some of the more
contentious items for now).
2. a method for proposing, debating, and accepting additions to this
standard, which will result in new versions of the standard.
3. a provision for individual applications (or groups of applications)
to add features in a way that does not conflict with what other
applications do. We need this to support `niche' application areas
that are probably not interesting enough to the world at large to
deserve inclusion in the baseline standard (and thereby support by
all conforming ABC applications). This should include a way for
ABC files to denote exactly which additional feature sets on top of
the ABC standard they need. (The namespace approach of XML seems
to be an interesting inspiration.)
4. a `reference implementation' of an application that reads a purported ABC
file and checks it for conformance to the current standard. It should
be made very clear that the written standard is what decides ABC
conformance, not `the reference application (or any other ABC application)
accepts it, so it must be conforming'. If the conformance-checking
application detects a violation of the ABC standard in an ABC file, it
should optionally output diagnostic information explaining it.
If possible this application should be built on top of an ABC-reading
library which is written in C (for maximum portability) and
published under a suitable license such as the BSD license, to make
it acceptable to both the developers of open-source ABC
applications and those who for whatever reason do not subscribe
to the open-source idea. For extra credit, this application (and/or
library) should be extensible to accommodate additions as per 3.
Such a library would be very useful to open-source developers,
while others could take it or leave it, as long as whatever they
came up with themselves did the same thing.
5. a `test suite' of suitable ABC files that allows developers to
check whether a given ABC application does `the right thing'. This is
obviously tricky since there are ABC applications that do lots of
different things, and what is `right' often depends on the application.
I have no magic recipe that will let us arrive at this blissful state
of affairs with none of the problems that we have experienced so far. I
still hope that we can get a bit closer, though.
There is no way that an ABC standard can be enforced other than by
`peer pressure'. However, for this it is necessary for the peers to
agree exactly where the pressure should lead.
Anselm
--
Anselm Lingnau .......................................... [EMAIL PROTECTED]
Nothing [...] will ever be attempted, if all possible objections must be first
overcome. -- The Artist, in _Rasselas_ by Samuel Johnson
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
