Linking Arms, Arming LINKs

[Thomas Dowling]

>
> Hi Thomas
>    I was interestede to read your message about your interest in the
> LINK element.  I can remember in 1995 using a German browser (forget the
> name) which implemented support for this element.  I was quite excited
> by this, but, as you say, Netscape and IE failed to support it.

That was the late lamented UdiWWW.  Windows Mosaic 3.0 also had a form of
LINK support, as does Lynx today.

>   Some examples of possible usages:
>
>   o  If a document is split into several files, use of <LINK="next"> /
> <LINK="previous"> should allow a user-agent to print the document with
> one user action.

True; if you offer a single document version for printing from your site,
you could also offer:

  <link rel="alternate" media="print" href="printable.html">

That requires more work on the server but demands less intelligence from
the browser.  And we all know how far we've gotten waiting for more
intelligent browsers.

>   o Offline browsers could have a better understanding of collections of
> related resources, and work much better.
>
> However as the list of relationships does not seem to have been formally
> standardised, I've a bit worried about AOL Netscape/Mozilla doing their
> own thing.
>
> They seem to be conflating standards and proposed standards.

I see this as a Good Thing Mostly.  I don't particulary want a formal,
exclusive set of relationships defined, but I do expect a robust
implementation to:

  Have built-in support for the most common relationships;

  Have built-in support for sets of relationships cited by
  widely referenced documents (like HTML specs);

  Have on-the-fly support for any arbitrary relationship
  I throw at it.

So while supersets of standards and not-quite standards is fine by me, the
actual conflating that's happening is a little bothersome.  We lose a fair
bit of descriptive power if, for example, the "up" and "top" relationships
are treated as the same.

>
> They are citing old standards and standards which never became
> standardised (e.g. HTML 3.0).  The links to some of the standards from
> <http://fantasai.tripod.com/qref/Appendix/LinkTypes/ltdef.html> are
> broken:-(
>
> It's not clear to me if LINK elements are still in the game as far as
> XHTML is concerned.

Yes, just remember to close them with "/>".  :-)

>
> It's not clear if a simple linear solution such as LINK elements is
> better than a richer more sophisticated solution such as RDF - which is
> the W3C recommended solution for metadata applications.

I don't really see the comparison.  LINK is simply a way to describe
relationships from one document to another; it isn't an attempt to provide
a metadata mechanism, although some of the relationships under discussion
parallel some common metadata elements.  The "meta" relationship even
seems to anticipate coexistence and cooperation between LINK relationships
and full-fledged metadata.


>
> There is a danger that there could be two divergent solutions (similar
> to what's happening with RSS).
>
> Also note that in
> <http://bugzilla.mozilla.org/showattachment.cgi?attach_id=40212>
> They say that:
> Section 6
> Meta Links:
> These links point to machine-usable data which should not be made
> available to the user.
>
> Why are they saying that metadata (such as author, title, etc) should
> not be made available to users?


That's not how I read this.  I perceive this to mean that a raw RDF
file--like a stylesheet, client-side script, embedded font, or P3P
profile--should not have a gesture in the user interface for the end-user
to view it.  That is substantially different from suggesting that users
should not have access to a parsed version of the metadata in the RDF.


Thomas Dowling
OhioLINK - Ohio Library and Information Network
tdowling at ohiolink.edu