This discussion is interesting, but is attempting far too much in one gulp.
Lets do something simple, effective, and non-restrictive, and then worry
about extensions later.
Ian
>
> I think we should start by looking at a list of meaning for REV and REL as
> descriptive attributes of links also defined by conventional HREFs.
>
> That is, they should express some sort of relationship between the source
> and destintation document locations that is refered to some sort of
> abstract model of hypertext and/or some notions of document semantics.
>
> For example: "This link/HREF is next in the linear order you should read
> this document".
>
> or: "This link points to the table of contents".
>
> Some of these have optional implications for browser behavior, some do not.
>
> The point that we might want to specify multiple relations seems quite
> reasonable, thought we can do this with multiple <LINK> tags in the <HEAD>.
>
> There is another class of REL (or something) attributes that may define
> browser behavior unrelated to conventional HREF links. As I noted before
> this is also depended on some abstract model: A "Back" button means
> something different for a history list than a history stack.
>
> I am skeptical about URI notation for hacking in browser behavior, but I
> might be convinced.
>
> However, I think we should decide what we are talking about before we fix
> the notation.
>
> Thus I'd like to see more than a list of REL names, I'd like to see at
> least one or two paragraph discriptions of what it is proposed that will
> they mean.
>
> I also think we should settle some basics (defining the REL values that
> have been floating around for some time) before we try to bring in the
> kitchen sink.
>
>
> ---
> Albert Lunde Albert-Lunde@nwu.edu
>
>
>