Not what Murray is trying to do. BIBLIOGRAPHY is not specific to Unix.
It is a common literary form. We can standardize this att value.
| 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.
NEXT, PREV, BIBLIOGRAPHY; yes, we can standardize these values. We need
have no mechanism built into HTML for extended *those values*.
| The legal community, scholarly community, and others will have to support
| their own characteristic REL values.
NEXT, PREV, BIBLIOGRAPHY are all relevant to scholarly work and, I suspect,
law, too.
| 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.
These are mostly the values Murray is working on.
| 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.
For general use we can define a short list that gets us somewhere. If
browser developers want to support others, they'll introduce them.
| > 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.
Nor I. It's not motivation that's at issue here, it's the specification
of semantics for common literary forms.
| 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.
Huh? You're telling us that we can't standardize a short list of REL
values. You're telling Murray he can have no recourse to this group
in pursuit of that end. I disagree entirely. REL is useless without
a common set of values that can be implemented by all browsers.
Establishing that set is a proper function of this group. Arguments
in favor of doing that are not "lobbying."
| > 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.
Problems that will always be with us. We're not dealing here with your
unclear "other issues." Nothing Murray has proposed prevents anyone
else from supporting other values for REL. The appeal to "communities"
is bogus. It's the HTML user community that needs standard REL values.
| 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.
REL values can't be deployed unless they're agreed upon. Murray was
able to do that in one closed system; what we need to do here is agree
upon a small set of common values that browser developers in general
can implement. "Testing" and "practice" simply won't get us there.
And are not needed for NEXT, PREV, BIBLIOGRAPHY, ...
-- Terry Allen (terry@ora.com) O'Reilly & Associates, Inc. Editor, Digital Media Group 101 Morris St. Sebastopol, Calif., 95472 occasional column at: http://gnn.com/meta/imedia/webworks/allen/A Davenport Group sponsor. For information on the Davenport Group see ftp://ftp.ora.com/pub/davenport/README.html or http://www.ora.com/davenport/README.html