First of all, the correct URL is
Second of all, as far as I can tell this document makes no mention of
glossaries. It mentiones the REL option of the <A> tag, but says:
>Used to describe the relationship of the linked object specified with
>the HREF attribute. The set of relationship names is not part of this
>specification, although "Path" and "Node" are reserved for future use
>with hypertext paths or guided tours. The REL attribute can be used to
>support search for links serving particular relationships.
This is in the section on hypertext links. Is there some other section
which describes glossaries?
>Um, no. Searchable just means that the server is set to up to respond to
>queries against that document. A query is formed by sending a URL to the
>server with a '?' and some text appended to it, such as:
>There are various ways of setting up a document as searchable. The example
>I gave was supposed to imply a CGI script that would examine the query string,
>look up a definition for the word or term, and return that definition as an
>HTML document. Anyway, that's outside the scope of the HTML design issues.
I hope I understand your example properly. I believe you were suggesting
that a script exist on the machine containing the glossary to handle
individual requests. This would (a) require that there be a server capable
of handling such requests on the computer holding the glossary, somthing that
not everyone has access to; (b) require the html author to know the proper
script for each individual glossary referenced; and (c) necessitate a new
connection for every search.
(a) and (b) take a relatively simple concept and make it very obscure for
the average user. Given a proper standard, this work could be done by
the browser and hidden from the authors of both the glossary and the
referencing html author.
As far as (c) is concerned, this is appropriate behavior for a *dictionary*
but not, I believe, for a glossary. The point of a glossary would be to
have a smaller list of vocabulary specific to a given subject. Since it
would be small, it could be downloaded in its entirety with the document
and then searched at leisure. Requiring a separate query over the internet
for each term investigated would be 1) prohibitively slow for many users
and 2) unnecessarily burdensome on the glossary provider.
A glossary is a very common, accepted form of information. It's not
unreasonable to make some sort of provision for it in HTML. If left
as a "browser issue" it will never be implemented on a wide basis.
>>should there be some way for an author to specify directly
>>which glossary he wants to reference for a particular word?
>Possibly. How would you do that without cluttering up HTML though?
Hmnn. Maybe it could be done as some sort of footnote. This would
take some thought, however.
>It seems to me that an author should not overload an acronym in a document,
>e.g. there should not be two possible interpretations of the acronym HTML.
>If one can expect a term to be used consistently throughout a document, then
>a little bit of intelligence on the server side ought to be able to resolve
>that issue without needing additional HTML features.
No, there should not be two possible interpretations of an acronym within
a document. However, when referencing a glossary one might encounter two
such intepretations. For instance, I was having a discussion with my
girlfriend last night when she used the acronym DTP. I thought "Data
Transfer Protocol", but she meant "DeskTop Publishing". She was using
it consistently, it was just that in the first (mental) reference list
I consulted I came up with an alternate definition. In a document,
one might want a glossary for networking and one for publishing. The
networking glossary might contain the Data-Transfer Protocol definition
while the publishing glossary might contain the DeskTop Publishing
definition. Though you might in general prefer to reference the networking
one first, in this case you would want to reference the publishing one.
Keith Rogers firstname.lastname@example.org
SECOM Intelligent Sytems Laboratory, Speech Processing Group
For an explanation of the above, see