And I think that, as a starting point for other aspects of OPES design, it
would be appropriate to include a collected glossary in this document.
my position, in all working groups, has been that putting glossaries
in documents is the signature of poor writing. at best, they're
redundant, at worst, they're contradictory. if the document can't
define terms in context as they are used, then there is a more
fundamental problem in the document...
If this document were the end of a process, I might agree. But (I presume)
it's laying some groundwork for ongoing cooperative design work, and for
that I think some common, easily referenced vocabulary is particularly
useful, in a FAQ kind of way.
all your comments were useful, but i'm going to focus on this one and let
others in the design team focus on the rest.
we're not starting in a vacuum. part of the problem with the opes specification
documents is that they are too long, verbose, etc., etc. the only way to get
agreement is to continually simplify and refine until either: a) there's
concensus on what's there, or b) what's there isn't worth doing.
either is an acceptable outcome to me. what isn't acceptable is spending a year
on bofs producing documents that very few folks can understand.
so, the current architecture document tries to avoid the problematic nature of
the previous set of pre-working group contributions by simply focusing on the
basics. as a part of that, some niceties, e.g., glossaries get lost. i can live
with that, because i'd rather not spend time having folks argue about
definitions and spend yet another year making no forward progress...
others' mileage may vary, obviously.
/mtr