I have found the debate interesting but now it is bordering on
redundant since I see little in the way of new ideas. Of course,
you may disagree and if so, just keep the old string alive.
To try to get a different view on the question, I am copying a string
from the html-wg that is discussing link relationships in LYNX.
Can we focus on a list and try to build a case from example?
(deductive vs inductive)
I know any list is bound to get *very large*. That is not the point.
Can any abstractions be found that withstand the scrutiny that this
list has to offer?
= all of these are content hierarchy structure relationships
except for the name literal they seem quite common and
well understood. There is the argument that not all entities
have these relationships, so this class must not be required.
= user aids?
= all of these are indices that may/should/do contain references
to this entity.
= related by same information in different representation form.
would we well applied to media "translations": text, video ...
= meta info about the entity
Having tried this, I feel a little better. I think we should be
able to come up with some system that will help make the online
world a little tamer.
Sure, this is beyond the pure land of meta-language. We knew that we
would have to go there in discussing links and style. Yes, these
"application" level details will make the standard less able to withstand
the test of time. We should make sure that these sections are separable
from the body of the XML spec.
<FLAME SUIT ON>
Please, help build something or prove that it can not be done.
Intellectual debate helps tune the thinking but proves nothing.
</FLAME SUIT ON>
------- Forwarded Message
Date: Thu, 23 Jan 1997 19:37:08 -0800 (PST)
From: Subir Grewal <firstname.lastname@example.org>
Cc: Lynx Development List <email@example.com>
Subject: Lynx and the LINK tag.
A few notes on Lynx's handling of LINK tags. After reading Peter's note
(that Lynx may not be handling all the standardized LINK REL/REV
attributes) I was curious enough to glance at the Lynx code to see what
was happening with LINK, I found it handles a lot more rel attributes than
I thought it did, though I'm not sure whether it handles all of the
standardized ones (but Fote's note gives me the impression these are all
the attributes defined in the DTDs for 3.0 and 3.2). Here's my
analysis of the scenario based on a cursory glance at the source code 
- -----Begin snippet from src/HTML.c-----
* Ignore anything not registered in the the 28-Mar-95
* IETF HTML 3.0 draft and W3C HTML 3.2 draft, or not
* appropriate for Lynx banner links in the expired
* Maloney and Quin relrev draft. We'll make this more
* efficient when the situation stabilizes, and for now,
* we'll treat "Banner" as another toolbar element. - FM
- -----End snippet from src/HTML.c-----
Now, extrapolating from the code that follows, I see that Lynx handles the
following REL attributes for the LINK tag (basically creating a toolbar,
using the attribute value as the linked text and the href value as the
href for the linki. If there's no href the tag is ignored).
Home ToC Contents Index Glossary Copyright Up Next Previous Prev Help
Bookmark Banner Top Origin Navigator Child Disclaimer Sibling Parent
Author Editor Publisher Trademark Meta Begin First End Last Pointer
In addition it does something special with the following REL attributes:
Home Help Index
And Lynx recognizes the following REV attributes:
owner made title
(Owner is used while constructing the info '=' page, as far as I know
that's equivalent to <!-- Owner_Name="some_text">, which is what I use).
As others have noted, it uses the href attribute (if it's a mailto: URL)
of a LINK REV=made to provide an easy mechanism to mail c'omments to the
Another brief note has to do with the manner in which Lynx constructs the
toolbar. It's true that the toolbar is only a keyclick away (the magic
key is '#'), but it doesn't stay on the screen all the time, I think Fote
though that would be inefficient when mose people are working with 24
lines (I agree of course).
Peter, If any standard LINK REV/REL attributes are not being handled by
Lynx, I'm sure the Lynx Developers would appreciate a little note to that
effect. In my experience, Fote and the others have always been very
forthcoming at incorporating handling for standardized/commonly-used
 Since I don't speak/write C, I may have misunderstood some of the
code, but I think I'm right in my interpretation especially since the Lynx
code is so wonderfully self-documented.
firstname.lastname@example.org + Lynx 2.6 + PGP + http://www.crl.com/~subir/
"This is a country where people are free to practice their religion,
regardless of race, creed, color, obesity, or number of dangling
------- End of Forwarded Message