[xml-h] 1/16 minutes of TAG on linking issues
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
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
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