It's still too complex I think. We don't need most of this stuff at
the moment, or at least there is no clear indication that we do. The
biggest issue that we hoped to resolve was the difficulty of an author
putting reliable links to 'common places' in a document (i.e. table of
contents, footnotes, etc.) and having these supported in a browser GUI.
This is adequately supported by Murray's proposal more or less as it
stands.
Anything more complex and we are defining a link model for the whole
WWW. This worries me, because we have given such a (big) problem nowhere
near the attention required to really solve it, and it isn't an issue we
can confine to HTML alone.
> Note that I don't think it is enough to consider REL/REV in isolation
> of their use. In my opinion, the lack of a well-defined *use* for
> REL/REV is a major reason why they were not implemented.
True, and we have found one such application in what SCO has done, and
agreed on another, that is, automatic creation of web maps based on REL/REV
values (proven in several generations of hypertext systems). I really don't
think we need to invent any more motivations. These two are enough to
motivate, respectively, a short list of navigation-oriented links that may
be activated using toolbar items in the browser rather than in the document
body (SCO's solution) and the ability to assign your own arbitrary REL
values. Neither of these causes a problem as all link behavior can still
default to 'goto (HREF)' safely. This is as far as the 'WWW link model'
really goes, and this is as far as HTML ought to go for the time being.
> I envision four useful (two new) attributes to LINK or Anchor elements:
>
> 1. Relationship definitions: REL/REV=.......
>
> This should *not* define the functional relationship between
> linked objects, but only the semantic relationship. Thus
OK, so the functional relationship defaults to 'goto (HREF)' in all cases,
and browser developers may not interpret a REL value to do anything that
is incompatible with this expectation (i.e. they cannot leave you on a
different page than the HREF indicates when the link behavior is over).
Fine. This supports SCO's online documents and other arbitrary REL/REV
values that are application-specific. SCO can lobby other vendors to
get them to support the SCO REL values in their own online documents,
but it isn't essential to allow SCO users to read SCO's online documents.
So I don't see a problem with the lack of specifying any REL/REV semantics.
> something like <... HREF="URL_B" REL="is_index" > means something
> like "URL_B is an index of A". Clearly the grammar for this needs
> to be clarified, as the last few letters on this subject have pointed
Yes. Crystal clear. And using unambiguous language wherever possible. I
for one think it is unfortunate that 'back' acquired chronological rather
than spatial semantics in the early browser implementations. I don't want
to invent a long list of names with sloppily-chosen semantics, that future
browser developers will be stuck with. If it isn't going to be implemented
*immediately*, it shouldn't be in the document. Let those who have the
time/inclination to think through the implications of the naming scheme,
do so for themselves at a later time. Drafts are only good for 6 mos anyway.
> out. Nevertheless, I think it is important that REL/REV does not imply
> a browser action (by which I mean things like cloning windows, replacing
> the current document, creating a popup miniwindow, a sidebar window,
> etc), although replacing the current document with the linked resource
> is the obvious default. It also should not imply what type of HTTP
> method should be used, although GET is the obvious default.
OK, so these values are "strictly informational" and browsers must interpret
them, cosmetic/presentation issues aside, in ways that leave you at the HREF
when the link is done processing.
> In a LINK element, the REL value can be used to indicate browser-
> preferred action. For example, if you had REL=is_TOC the browser might
Careful. If REL values can be safely invented by authors in an A element,
they must be able to use the same values safely in a LINK element. It's
a disaster to be able to use REL=index in an A element with no problem,
but have the very same clause invoke unpredictable behavior in a LINK.
If you want to say that browsers are not even allowed to attempt cosmetic
'optimizations' (like button bar support, floating footnotes, etc.) for an
A element but are allowed to attempt such presentation hacks in a LINK, it
might work, but you have effectively got two namespaces now: one strictly
author-defined in A elements, and one that is interpreted by the browser in
LINK elements. You really should not call both of these the 'REL' attribute
as they are serving two different purposes. In use they can only diverge.
> have a preferred (if it is a graphical browser) icon-bar entry to
> bind to this relatinship, and might even have a preferred browser
> behaviour (such as cloning a window) once this type of LINK is accessed.
Fine, if and ONLY IF that *also* works in an A element.
> In an A element, REL could be used to provide additional information
> about a link, for example as a balloon help message when the cursor
> is left lying over anchored text. If a TITLE attribute is present,
> this information would also be presented as part of the balloon help.
This behavior would be just as useful for an A or a LINK. I see no
rationale to allow REL to be interpreted so differently for each element.
> If we want REL/REV to contain additional information about a link,
> then these pieces of information should be separated by a defined
> separator from the defines semantic names. For example:
> "IS_TOC/Table of Contents for the Professional Bowling Web Site".
> I prefer putting this information in a TITLE attribute.
I agree, put it in TITLE, don't start inventing complex names. If we
are going to have a proper name space for such 'semantic names' then
we are better off using the hierarchy to denote [link-set]/[link-type]
than [link-type]/[link-name]. Let's not burden the authors too much.
The reasons not to have a 'defined separator' enforced in HTML have been
quoted by someone else on this list recently. This was given as one of
the rationales to avoid the URL-like "linkas:..." syntax for link type
names. Let's not cause the same problem, this time for much less gain.
The link anchor text is already there for very specific link implication
data. REL/REV are intended to provide more general semantic relationships.
Think in terms of object-oriented type definitions (where names/roles are
intended to converge and be standardized) not entity-relationships diagrams
in the classic sense (where roles are encouraged to proliferate). In HTML
the 'proliferation' is supposed to happen in the link text, while standard
semantics for the relationship should be assigned with the REL attribute
(or whatever ultimately succeeds/augments it).
> 2. Information about the linked resource: TITLE="title"
>
> Information over and above the semantic relationship between
> two objects could be expressed in the TITLE attribute. This is
> consistent with older definitions of TITLE.
Better than putting it in REL/REV.
> 3. Browser Behavioural Hints: ACT=CLONE|REPLACE|POPUP|SPLITSCREEN.....
>
> It seems reasonable to allow the author to suggest browser behaviour
> when links are activated. For example, when I click on a LINK button,
As long as 'suggest' is just that, and as long as the semantics of
navigation (which are a WWW-wide global issue that go beyond HTML)
are not affected.
> 4. Link Action: METHOD=GET|TEXTSEARCH
> ...
> This requres standardized methods and data encoding schemes. There
> is only one, namely the HTTP TEXTSEARCH method, which is how ISINDEX
> search data are sent to a server. I therefore propose that the
> METHOD attribute have two possible values, namely GET|TEXTSEARCH,
> to indicate how the client should access the linked resource.
> nice to have this
OK, so your use of METHOD is consistent with forms. I don't think that
this introduces any issue that is not already there with its use in forms.
Each METHOD can define its own way of mapping attributes to method call
parameters, as they do now. This is not as good as having one way to do
it but if some more general solution arises (like the 'link stylesheet')
it can be supported later.
I take it that you are defining GET to mean:
"call this function with the attributes from the (A or LINK) tag where
METHOD=GET appears, retrieving a function to implement the presentation:
howto_gotoHREF = GET (ACT, REL)
run the resulting function with the argument HREF that appeared in the tag.
howto_gotoHREF (HREF)
(where ACT, REL, and HREF are the attribute values appearing in the tag)"
I still think we need a general purpose way to define such mappings, but
pushing them through the HTTP standards committee is the way for now...:-)
-- Craig Hubley Business that runs on knowledge Craig Hubley & Associates needs software that runs on the net mailto:craig@hubley.com 416-778-6136 416-778-1965 FAX Seventy Eaton Avenue, Toronto, Ontario, Canada M4J 2Z5