Re: Link style sheets [was REL and REV]

Craig Hubley (craig@passport.ca)
Mon, 15 May 95 06:07:01 EDT

OK,

You've (all) convinced me that a URI-based solution is impractical in
the near term, at least for HTML3, as there seem to be several means by
which link type names could be bound to a specific list of actions:

- strictly internally, by a proprietary mechanism in the browser itself
(this has to be done anyway for SCO's short list of navigation actions)

- in a separate advisory attribute (as Ian proposed) listing the actions

- a 'link stylesheet' or other network-based entity listing 'action per REL'

- a CLASS (as suggested again below)

- an 'applet' facility (such as HotJava has)
(I don't like this, I can't write an 'applet' to process a LINK tag)

- a URI mechanism (as I originally proposed but which needs more work)

- a CORBA-like mechanism (which the OMG has already standardized)
(this might sit 'under' a URI mechanism)

Even choosing which of these is best would be a chore. Not only that,
there are other reasons to look up shared functions over the network,
such as field and form integrity, sharing common CGI scripts, etc., not
to mention ensuring that links to HTML from other types of documents work
as expected.

NEW PROPOSAL-------------

At this point I suggest that we concentrate on the list of values that
the browser itself is expected to understand. Values that the browser
does not recognize would simply default to the 'goto' behavior. Thus a
LINK tag behaves like an A tag if it lacks a REL value, or if its REL
value is not recognized by the browser. Is this OK ? This lets authors
define their own link role names. This is necessary to generate web maps.
(Note that the navigational link roles: next, previous, etc., are no use
at all for this - knowing these roles doesn't help you filter links much).

The only names that would be 'out of bounds' for authors are those that we
hardwire into browsers in the standard. To help keep straight which those
are, and accomodate expansion of nonstandard link roles, we should prefix all
new names with an 'escape' (Lee's REL="X-nonstandard" suggestion) which we
might later bind to a URI (in other words, set X=(some net location) in some
new tag (as Joe and Lee suggested). This can/must wait until there is some
standard way to retrieve a link role over the network (probably not soon but
I'll work on it with the URI group, I already have to do this for "SQL:..."!).

The 'X-' prevents accidental name stomps. Let's encourage browser developers
and authors who extend the list of values, to be nice about name space and
pick names for their tags like: X-SCOnav-glossary, X-SCOnav-webmap. I
still anticipate problems with potentially popular link type names like:
X-legal-precedent, X-legal-jurisdiction, (which many parties might define).
But then perhaps the name clashes would encourage these authors (lawyers?)
to reach some consensus on usage, which in the long run would be better
than a lot of browser- and institution-specific link type names.

I think that this proposal is now identical to Lee's original proposal.

END PROPOSAL--------------------------

> word "function" etc. in various contexts. It sounds like you are
> talking about something in the vein of an object-oriented programming
> language.

I'm not trying to *invent* one (unlike Sun :-) ) but I am definitely trying
to reconcile the way an author specifies the role of a link, and the way
that is interpreted in the context of a document,

There already exist standard ways of distributing objects and methods to
many co-operating programs across a network (i.e the OMG Comon Object Model
and CORBA standard). They are widely implemented (more on LANS than on the
net though) and provide a natural basis for a network protocol to look up
functions.

> If it's purely an abstract space of function defintions according
> to various authorities, it seems like treating it like CLASS and
> defining a different space makes sense.

This would be fine, as long as you can use the name as an attribute value
and it will be bound to the right function when required.

> If the function defintions are stored out on the network, we can
> reference them with an ordinary URL with a protocol scheme like http://
> or ftp://

Yes but we don't know what browser the user is looking at the document with.
Therefore the document doesn't know what kind of function/patch to point at.
Creating a protocol to resolve this doesn't seem to have much support here.
Leaving it up to the browser vendor / server pair doesn't seem to either.
I think we are going to end up letting Sun or Netscape or someone do it first.
Hopefully not too many incompatible solutions will develop.

> Is this purely a space of "function" names? Or would we offer
> some abstract model of what these "functions" are allowed to have
> as inputs, outputs or side-effects?

For link roles, the functions have an argument which is the destination,
and an output which is the destination, and all that changes is how one
gets there. It's possible to imagine things like 'embed' that might leave
you on the original page (thus the output is the origin not the destination).
A link role is mostly side effect.

An abstract model could be defined in OMG Common Object Model or ASN.1.
That is, we could specify in the standard that when this tag is 'activated':

<LINK
REL=next
HREF="there.html"
>

this function (in C++ format here, sorry my ASN.1 is rusty) is called:

destinationDocument originDocument->next("there.html");

That is a pretty minimal 'abstract model'. Not very controversial.
It might be useful to state such a correspondence very clearly, for
any tag that actually implies a specific browser action to happen.

> It seems like defining things well enough to make browser
> functions interchangible between browsers is a lot like defining
> a programming language or at least an API for calling an object
> file format. This is potentially a "big" project. (To say nothing
> of raising issues of "safe" scripting, tojan horses and whatnot.)

Absolutely. That's why I'm backing off from it, for now. There is
simply too much controversy over the 'best' way to define functions.

> The original project of defining some "core" link relationships and/or
> browser behavior could be a lot "smaller" in scope.

I hope my suggestion above will leave the door open to a more complete
solution later, and let us get on with the work of defining a 'basic'
set of link roles for HTML3. I for one would favor 'just' SCO's four,
since they represent actions implemented in any reasonable WWW browser,
and are non-controversial.

-- 
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