Link types

Greetings,

In the specification of link types in the current 4.0 draft [1] there
seems to be no way of moving up in a tree structure.  There is also
some vagueness about the link semantics, and ambiguity in the
specification of alternate versions.

I feel it's very important that the 4.0 spec make some sort of
decision about _the_ list of link types, so that there's no excuse for
browser manufacturers to fail to catch up with (for example) lynx.

The draft says `[a]uthors _may_ use the following recognised link
types' (my emphasis).  I think we could get away with a much more
definite statement, along the lines of saying that if the link element
is supported at all by a browser, then all the types in a given list
must be implemented in some way, and that all alternatives with the
same semantics (such as `toc' instead of `contents') are deprecated.
This wouldn't close the door to future extensions, but it would
encourage authors to take the trouble to include LINK elements in
documents they generate, and encourage manufacturers to include
support for them, in the expectation that there will be enough
structure encoded in the head element to make useful nagivation aids
feasible.

I don't think we need worry if we end up with a spec with a lot of
structure in it.  I'd think that in most cases where there is metadata
like this, the documents in the set will have been generated
mechanically from some other source, and getting all these fiddly
relationships correct is just what the damn machines are good for.  In
any case, the relationships that are likely to be used most often (or
at all, when the stuff's being written by hand), such as MADE, are the
simplest. 

Specific points:

1) In other documents suggesting link types (including [2] and [3]),
I've seen rel=up, rel=parent and rev=subdocument as possible ways of
indicating that a document has a parent.

2) What does rel=bookmark mean?  Is it something that you're
suggesting is worth bookmarking?  Is it a suggested entry point?  Is
it necessary in a minimal set?  Also, is rel=start a link that should
be required to be in every document in a collection, if it's in any
one of them?

3) <link rel=alternate media=print href="..."> doesn't allow for more
than one format of document, and gives no clues about the format of
the document.  In [4], there's a suggestion of a TYPE attribute giving
a MIME type.  If there's a MIME type, the MEDIA attribute might be
redundant.

4) The rev=made link isn't listed!  This must be the single link
relationship that's most often used by authors.  I know that there are
other possibly better ways of specifying the authorship relation,
using the DC set for example, but unless we're going to abandon the
LINK element altogether, and place all this navigation structure in
META elements (as has been suggested here already), I think that MADE
does have to be there.  Just by the way, should the HREF for a
rev=made link be a link to a home page, or a link to an email address?
I can see either being defensible.

All the best,

Norman


[1] http://www.w3.org/TR/WD-html40/struct/links.html#h-7.6.2.5
[2] http://www.w3.org/pub/WWW/TR/relations.html
[3] http://www.sq.com/papers/Relationships.html
[4] http://www.w3.org/pub/WWW/TR/WD-htmllink#link and
    http://www.w3.org/TR/WD-print 

-- 
---------------------------------------------------------------------------
Dr Norman Gray                                       norman@astro.gla.ac.uk
http://www.astro.gla.ac.uk/users/norman/

Received on Thursday, 10 July 1997 07:29:32 UTC