[xml-h] How semantic are links?

Sun Jan 19 22:45:46 GMT 2003

On Fri, 17 Jan 2003, Norman Walsh wrote:
> 
> Ok, now the question is, in your mind, are the links in your
> documents more like elements and attributes, things that are "baked
> in" semantics, or are they more like style?

A bit of both.

Let me quickly introduce myself: I'm an invited member of the CSS
working group and I've been involved with Mozilla's standards
compliance QA for around four years. I haven't studied linking theory,
or any other theory for that matter (I studied Physics). My experience
is based entirely on practical experience developing a Web browser and
writing stylesheet specifications.

As far as I can tell, there are two main ways of classifying a simple
hyperlink:

 1. Whether the linked resource is an intrinsic part of the document.

    This is the difference between an <a href=""> link, and an <img
    src=""> link (the former is a hyperlink, the second is a link to
    an external resource that is an intrinsic part of the document).

    If you want to make a complete copy of a document, then you will
    want to copy all the resources that are intrinsic parts of the
    document, but none of the other resources to which the document
    links.

 2. The intended use of the resources: as a separate resource (another
    document, an image, a sound file), or a resource that augments the
    current resouce (a stylesheet, a script, an icon, a
    transformation).

    In the case of a separate resource, the link can be further
    labelled: Is the resource the logical next resource in the overall
    site, is it a glossary, or a resource to use when providing
    feedback, is it a pingback server [1], a link that represents the
    canonical URI for a resource ("permalink"), etc.

Note that the above says nothing about how the link should _behave_.
That is the realm of stylesheets, transformations, or behaviours built
in to the UAs.

For example, a link to a separate resource may be rendered inline, as
in an <iframe> element. Or it could be simply represented by blue
underlined text which, when clicked or otherwise activated, causes the
UA to replace the current resource with the linked resource.
Similarly, an embedded resource could be represented as either of
those presentations, or it could be rendered as a footnote, or a popup
window activated when the page first loaded.

The important point is that presentation and behaviour are independant
of whether the linked resource is a part of the current one or not.

Of course, in addition to one-to-one links embedded in the content, we
also have forms, one-to-many links, image maps, and external link
bases. All of these are, in my opinion, exciting concepts.

 * Forms are a complicated matter. The HLink [2] specification
   attempts to address these but in my opinion this is better left to
   form-related specifications, as the problem easily doubles in
   complexity once forms are introduced.

 * One-to-many links are, as far as I can tell, effectively many
   one-to-one links originating from the same source. As such, I don't
   think they need special treatement at layers below the presentation
   layer. In fact, Bob DuCharme showed this quite well [3]: if you
   look at his content, it is merely a set of one-to-one links
   embedded in a container that a transformation or binding [4] layer
   can turn into a clean user interface.

   Note that one-to-many links are commonly used on the Web, although
   typically by overloading the <select> element [5].

 * For an image map, you have a many-to-one link with coordinates and
   an embedded resource on which to base the coordinates.

 * External link bases are significantly less common than the other
   three, but are still an interesting technology. At the simplest
   level, they are identical to normal inline one-to-one links, but
   with a "source" URI given in addition to the target URI and
   metadata listed above.

Down at the XML level, if we're considering how to give XML UAs
information on what elements and attributes represent links, then
taking the above into account there are several features and
requirements that come to mind:

* It is important that a single element be able to link to more than
   one resource. Not simply for many-to-one links, but also to support
   languages with elements that contain links to multiple related
   resources, for example

      <image
         src="image.jpeg"
         thumbnail="image.png"
         description="image.html"
         cite="http://www.example.net/"
         href="http://image.example.com/"/>

   Here we have three links to resources that are intrinsic parts of
   the documents (the image itself, a thumbnail version of the image,
   and a description of the image), and two links to external
   resources (one to the site from whence the image came, and one to
   the site that the image represents).

   This, I believe, is the main problem with XLink [6] and SkunkLink
   [7]: They do not give a way for attributes to be labelled as
   particular types of links, instead introducing their own elements
   and thus limiting linking to one (for XLink) or one of each (for
   SkunkLink) per element.

 * It is also important that it be possible to associate each
   attribute with another attribute that indicates the role of the
   link (much like the "rel" attribute is for the "href" attribute in
   HTML). Similarly, we need "shape" and "coord" equivalents.

   The roles are varied -- the current set of roles given for the HTML
   "rel" attribute needs extending.

 * However, it is important that we not state, at the markup level,
   what presentation is expected. This is something that XLink and
   HLink both get wrong, in my opinion.

It would be nice to see a language, at the schema level, like XLink,
HLink, or SkunkLink, that addressed these issues. So far, none of the
solutions have hit what is, in my opinion, the set of requirements for
links in XML.

-- Footnotes --

[1] Pingback server: A server which accepts notifications that another
resource has linked to this one.
   http://www.hixie.ch/specs/pingback/pingback

[2] HLink: Link recognition for the XHTML Family
   http://www.w3.org/TR/hlink/

[3] "1-to-many HTML links, prototyped", Bob DuCharme
   http://lists.usefulinc.com/pipermail/xml-hypertext/2003-January/000027.html

[4] Binding layer: An extension to the presentation layer that allows
dynamic behaviours (event handlers, etc) to be bound to parts of the
document. HTCs and XBLs are binding layer technologies.
   http://www.w3.org/TR/NOTE-HTMLComponents
   http://www.w3.org/TR/xbl/

[5] Examples abound, for example on ABC.com, at the top right, next to
the FIND button, there is a drop down list which acts as a primitive
one-to-many link.
   http://www.abc.com/

[6] XLink: XML Linking Language
   http://www.w3.org/TR/xlink/

[7] SkunkLink: A Common Ground for XML Linking
   http://dubinko.info/writing/skunklink/

-- 
Ian Hickson                                      )\._.,--....,'``.    fL
"meow"                                          /,   _.. \   _\  ;`._ ,.
http://index.hixie.ch/                         `._.-(,_..'--(,_..'`-.;.'