Obviously I should clarify, although no one other than you seems to have
read what I said this way. This is not an accusation. I simply said there
is an alternative way to achieve standardization of specific REL values
in a specific community: Unix documentation developers. SCO's group is
part of this community. Obviously they have an interest in compatibility
with their existing work, and they have an interest in getting their work
supported rather than supporting, say, a set of REL values invented by
Microsoft. They may have to do (what I describe as) "lobbying" anyway,
among third party developers, to ensure products shipped for SCO fit into
SCO's own documentation web. But this is a different process from writing
a standard. I simply observe that the html-wg can't write this standard
for everyone.
The legal community, scholarly community, and others will have to support
their own characteristic REL values. Whoever is first in *those* communities
to fix a set of REL values will obviously have a similar interest in getting
those values supported. In some cases those values have hundreds of years of
tradition and documentation behind them. This will not be set aside in order
to become compatible with *any* short list that we define, no matter how well
proven or implemented.
> on behalf of SCO. He's making a proposal, the value of which he has
> shown (to himself and some other folks) with an implementation. His
I seem to have taken this for granted. I am not inclined to accuse people
of narrow motivation in standards meetings, and I have sat in quite a few.
In our current terms of reference, I could say that I do not believe that
<LINK REL=is_unfair_to HREF="proposer"> belongs here. I request that
you leave it out, but I should not have to author a standard to exclude
it. A similar 'social' protocol is adequate to define most REL value usage.
> proposal is of general interest. There is nothing proprietary about
> it (indeed, he'll probably have to adjust his implementation when
> the dust settles). It is not limited to vendors of anything.
My point exactly. Many communities will be building on this mechanism.
Not all of these communities have been tested by SCO's implementation,
which seems to focus on problems of navigation and online documentation
of documents with a traditional structure. Other issues are less clear.
So let's err on the side of conservatism, and give others room to test
their own REL values, and let practice lead the standard there too.
-- Craig Hubley Business that runs on knowledge Craig Hubley & Associates needs software that runs on the net mailto:craig@hubley.com 416-778-6136 416-778-1965 FAX Seventy Eaton Avenue, Toronto, Ontario, Canada M4J 2Z5