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?


Home 
Up 
Next 
Previous (Prev)
Top 
Child 
Sibling 
Parent
Begin 
End 
First 
Last 
  = 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.

Banner 
Navigator 
Help
Bookmark 
Pointer
  = user aids? 

ToC 
Contents 
Index 
Glossary 
   = 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 ...

Copyright 
Origin 
Disclaimer 
Author 
Editor 
Publisher 
Trademark 
Meta 
  = 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>

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
owner.

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
markup.

[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

Received on Friday, 24 January 1997 11:06:08 UTC