W3C home > Mailing lists > Public > www-html@w3.org > August 1998

Re: LINK Element Confusion

From: Frank Boumphrey <bckman@ix.netcom.com>
Date: Sat, 15 Aug 1998 01:35:02 -0400
Message-ID: <003301bdc80e$782db280$04aedccf@ix.netcom.com>
To: "John T. Whelan" <whelan@physics.utah.edu>, <www-html@w3.org>
John T. Whelan


>>>Under B4, the paragraph, "Indicate the Beginning of a Collection",
>>>states use rel="start" but the example that follows has rel="begin".
>>BEGIN and START mean the same thing do they not?
> But of course if we want automated indexing agents to deal
>with LINK data, we need to have a standard set of definitions that
>don't require the bot to have a thesauraus.

I agree

>> Both REL=START and
>>REL=BEGIN merely indicates that the document the link is pointing to can
>>considered the start in a series of documents.
>>> Maybe it
>>>would be used more if the average HTML author could be given a simple
>>>explanation of its use and a simple set of rules to follow.
>>OK On every page you make put the following
>><LINK REL=START HREF=[homepage url]>
> What about the situation where a set of pages form a unit with
>a logical starting point, but the whole family is actually a sub-unit
>of a larger whole?  For instance, I have an alternative sports site
>with a bunch of stuff on it, including a set of pages for an amateur
>baseball team.  Is it reasonable to say that all of those pages have
>as their REL="start" the team homepage, but then to say that the team
>homepage is actually part of the alternative sports site, so it has a
>LINK REL="start" pointing to the homepage of the whole site?  That
>seems like a good way to encode that sort of hierarchical structure,
>although one might argue that the START page can't have a START page
>of its own.  (One could demand that PREVIOUS to label the intermediate
>step--here the team homepage--but that implies a sequential ordering
>that doesn't make sense to me.)

Actually I think START is just a message to a 'bot' to tell it where to
begin searching.

 I think it is better to think of "collections of pages" each with its own

On my private web site, I have a collection of 'font pages', of 'typography
pages', of 'CSS pages' etc, each with their own index page.

I should have a minimum of two link tags, one REL=START telling a Bot where
to start, which would logically point to the root page of the whole document
collection, and another REL=INDEX indicating the index page of the
individual collection.

I see no reason why the index page of the individual collection of pages
should not itself index the root page as its index, so in each index page we
would have

<LINK REL=INDEX HREF="../index.htm">
<LINK REL=START HREF="../index.htm">

The one tells a Bot where to start the other gives some other agent
information about the structure of my site. If I labelled all my pages
properly, a user-agent should be able to make a tree structure, and use each
page as an object.

I suppose in OO terms we could think of each page as an object, and several
pages belonging to a class.

> And what about joint endeavors?  It it kosher to have two
>different LINK REL="start" tags if there are two independent pages
>which can claim to be the immediate parents of a page?

I didn't think in OO theory there could be two parents. Each object is a
"Virgin birth"<g>

But of course many sites have a neuronal structure, with multiple
interlinked pages (although I believe this is bad design, but that is
another story) in which case all pages could claim to be the start page of
all the others. Probably best to arbitarilly define one page as a start page
to ensure the poor bot doesn't have a nervous break down!

As a Professor of relativity of course YOU should have no difficulty with
neuronal structures<grin>
>PS--You left out LINK REV=made, which has been used by at least one
>browser for a long time.

FMI: -Which one?

Regards Frank

Frank Boumphrey

XML and style sheet info at Http://www.hypermedic.com/style/index.htm
Author: - Professional Style Sheets for HTML and XML http://www.wrox.com
Received on Saturday, 15 August 1998 01:29:53 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:48 UTC