[xml-h] 1/16 minutes of TAG on linking issues

Bob DuCharme bobdc at snee.com
Thu Jan 23 18:28:07 GMT 2003


Being way behind on mailing lists, I only read this today: 
http://www.w3.org/2003/01/16-tag-xlink, the Minutes of 16 Jan 2003 
discussion on Linking in XML Documents. It provides plenty of fodder for 
discussion on this mailing list, so I recommend it to everyone. I wanted to 
throw out my opinion on what I saw as one of the most important issues: 
whether specifying that something is a link makes more sense when done 
externally.

To sum up, (with my own elaborations that I encourage others to correct if 
misguided): an external "stylesheet" that identifies that a given element 
is a link, as proposed by the Opera CLink document at 
http://people.opera.com/howcome/2000/css3/clink-nov-6.html, has the 
advantage that the link's presentation semantics don't have to be 
hard-coded with the link itself. This provides the classic benefits of the 
separation of content and presentation, e.g. the resource referenced by the 
link could be treated as a pop-up window in a web browser rendering and as 
a sidebar in a printed rendering. The "type" of the link in the markup can 
be something that semantically describes the relationship between the 
linked resources (e.g. the disposition in <citation caseID="roe.v.wade" 
disposition="concur"/>), instead of giving clues about the 
presentation--that's something to store in the stylesheet.

The counterarguments, all through direct quotes:

Tim Bray (TB): "problem with CLink is that it's external-only (right?) 
makes life harder for spiders."

Tim Berners-Lee (TBL): "Should be able to infer links with only the 
document available."

TB: "TBL wants potential for 100% self-descriptive links with no call-out 
to another resource."

Henry Thompson: "this is the View Source argument again."

TB (later) "I like CLink (elegant) but nervous that will make life harder 
for robots, spiders."

TB: "the Web brought a new thing into the world: the notion that content 
should contain embedded actionable pointers to other content. You don't 
have that, it's not the web any more."

My own opinion: the use of markup in one resource to reference another ) is 
something that we can identify as a link without requiring mandated 
standard markup to say "this is a link." The element <citation 
caseID="roe.v.wade"/> is a link if the processor understands the semantics 
of the address. (If the processor can't understand the addressing 
semantics, then you've got other problems. It will typically be a URI, but 
I deliberately used a non-URI example.)

This view does have one problem, the URIs-as-names-vs-addresses problem: 
when a processor sees <foo bar="http://whatever"/>, if it can assume that 
the URI references something real, it's a link, but if it's possible that 
the URI is just a name, then the processor will need help from somewhere, 
either external or internal, to know whether to follow this potential link. 
Practically, we can probably enumerate the places where it doesn't identify 
something real--in the value of an xmlns or xmlns:* attribute, in certain 
RDF contexts, etc.

Comments (especially from Norm, who is part of the TAG)?


Bob DuCharme          www.snee.com/bob           <bob@
snee.com>  "The elements be kind to thee, and make thy
spirits all of comfort!" Anthony and Cleopatra, III ii
(NOTE: bobdc e-mail address used only for mailing lists;
please send private e-mail to bob@)




More information about the xml-hypertext mailing list