Nonetheless it is better. This strongly suggests that we should continue
the 'REL is a verb' convention where possible, and prefer, say, REL values
like 'REL=indexes' rather than 'REL=index' (as I whined about earlier).
However, for any general purpose link model, which would for all practical
purposes have to be based on some general purpose object-oriented model (i.e.
OMG's COM, Microsoft's COM, now merging), the subject of such a 'verb' is the
current document and its object is the document that is HREFfed. Thus this:
...appearing in "this document"...
<LINK REL=indexes HREF="other document">...
would be interpreted as:
"this document" indexes "other document"
Argh. You are right. The semantics are the opposite of the general purpose
object model that is implemented already in most LAN-based network software.
The OMG model does, thankfully, specify, that behavior can be looked up based
on the *combination* of 'this document, 'indexes', and 'other document' but
anyone used to single-inheritance object-oriented systems will get confused.
We had better fix this. Now. I would even prefer REL=is_indexed_by rather
than leave this ambiguous. I predict horrible problems once non-hardwired
functionality is implemented in browsers if we leave this sort of thing
unclear. If HotJava APPLETs could be REL values now we'd be seeing it now.
In case this is unclear, imagine this scenario. I write a pile of useful
functions that transform, index, and map HTML documents. I put them in a
LAN-based object oriented repository, assigned to the object type 'HTML
document'. Now someone *else* writes a mapping program that goes off into
the web, interpreting REL values, and calling my functions on them. Some
people use REL=index to mean "'other' is the index of 'this'", some use
REL=indexes to mean "'other' indexes 'this'", some use REL=is_index_of, etc.
His mapping program now has to be artificially intelligent to know what the
heck the author meant with his REL value. *Even if* all authors use the
currently 'standard' meanings, the mapper-developer has to remember that,
if he sees in document A: <LINK REL=index HREF=B>, that means 'B indexes
A', and has to invert the function in order to call my function of form
(again as in C++):
HTMLdocument->index(HTMLdocument other);
Therefore he has to call B->index(A) rather than A->index(B). *Not* what
an experienced object-oriented developer would expect to do while processing
A. Sigh.
However, an *overly* experienced object oriented developer, or any LISP-
head (more or less the same thing), would be calling index(A, B) or even
lookup(index, A, B), or equivalent in another generic model such as C++
templates, and not expect the behavior to be defined in any of the involved
objects. As one of these overly jaded folk I would probably not care, but
I am very concious of the effect of this kind of stuff on my juniors:
Anyone remember the first time you tried to explain why an X desktop
program was the 'server', and the application over the network was the
'client' ? In my estimation this kind of thing causes misunderstandings
that lead to tens of millions of dollars of wasted effort over many years.
> > +-----+ PARENT +-----+
> > | A |---------> | B |
> > +-----+ +-----+
> >
> > To me this says
> >
> > "A's parent is B"
'parent' too has ambiguous semantics. Parent/Child are extremely ambiguous.
> > (Murray's paper has the same interpretation.)
Yes. Therefore I think we should deprecate REL or define very very clearly
what we mean.
> I still think the definitions I gave are more accurate -- both
> REL and REV do specify specific source and destinations (assuming we
> don't invent multi-ended links).
>
> > Are you saying that the WWW link model really
> > interprets this as
> >
> > "A is the parent of B"
> >
> > instead?
>
> No, I'm saying that the WWW link model does not adequately define
> the meaning of relationships based on noun phrases.
Hmm. This had better be fixed, and damn quick, with a very clear mapping
to the OMG Common Object Model, which is now almost universal among LAN
systems. Frankly I don't care which way it goes, I think any standard
or convention that is intuitive will prevent a lot of wasted effort. I
think this note makes it clear why I think 'how to find a function over
the network' is a serious, WWW-wide, problem, and why I think it affects
the choice of REL values and naming scheme.
> >> RECOMMENDATION: Abandon this model. Declare REL and REV to be deprecated,
> >> and replace them with ROLE="" (defined in SGML as type NAMES)
> > Is this:
> >
> > <link ROLE="next" href="xyzzy.html">
> >
> > any less confusing than:
> >
> > <link REL="next" href="xyzzy.html">
> >
> > Ah, I see... "REL" labels the link, while "ROLE"
> > would label the *target* of the link. Correct?
>
> Yep.
Extending my model as above, <link ROLE="next" HREF="xyzzy.html">
translates to:
(this document's role of) 'next' (is played by) xyzzy.html
and thus (in C++):
this->next("xyzzy.html")
or a generic function
role (this, "next", "xyzzy.html").
This will definitely make me sleep easier at night, unterrified by the
horrors that junior coders will have prepared for me at 4 AM for the
next morning's review. :-)
> > Would it be possible to simply change the official
> > interpretation of the "REL" attribute to match
> > existing practice? (SCO's browser for one, and
> > I know of at least one document that makes heavy
> > use of <LINK> with relations defined as above.)
>
> Yes. We could instead define a consistant semantic for noun phrases.
> For example:
>
> when link type = noun, then SRC's REL is DEST
> DEST's REV is SRC
>
> when link type = verb, then SRC REL DEST
> DEST REV SRC
Ye gods! Isn't "INDEX" *both a verb and a noun* ? I can "index" a
document, and it can also be an "index". Nooooooo!!!!!! Don't make
this depend on the English language semantics of words that are, by
definition and design, the most generic words in the language...!
> which works only so long as you can differentiate between
> nouns and verbs (probably not a problem). In that way, we can
> at least provide guidance to authors regarding how to name a type.
DEFINITELY a NASTY problem. I suggest we avoid any words that can be
both verbs and nouns, deprecate REL, and try to switch over to ROLE.
-- 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