Taxonomy List

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?

Previous (Prev)
  = 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.

Translation Bibliography
   = 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.

Please, help build something or prove that it can not be done. 
Intellectual debate helps tune the thinking but proves nothing.

Dave Hollander

------- Forwarded Message

Date: Thu, 23 Jan 1997 19:37:08 -0800 (PST)
From: Subir Grewal <subir@crl.com>
To: html-wg@www10.w3.org
Cc: Lynx Development List <lynx-dev@austin.sig.net>
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 [1] 

- -----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
Translation Bibliography

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

[1] 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.

hostmaster@trill-home.com  +  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
keys ..."

------- End of Forwarded Message