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

Simon St.Laurent simonstl at simonstl.com
Fri Jan 24 10:17:48 GMT 2003


bobdc at snee.com (Bob DuCharme) writes:
>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.

Thanks for pointing this out - it's well worth reading as a base point
indicating where the discussion at the W3C is today.

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

The distinction between "processor knowledge" and "mandated standard
markup" seems to be where most of the friction takes place.  The early
XLink specs had an interesting standard meta-markup for setting up
processor knowledge, but that seems to have been discarded as namespaces
- effectively mandated standard markup - moved in.

In practice, I've been happiest with the Opera approach you mention [1].
Opera's had a simple set of tools for linking through CSS since version
4 (that apparently came from its early WAP work).  Using those tools,
it's very easy to create links in XML documents, whether or not you
choose to use the XLink vocabulary.[2]  I think that foundation would
also work for implementing SkunkLink, with the possible exception of
nested links - though CSS seems an appropriate place to specify their
presentation.

There seem to be people who worry about the extra complications this
provides for link harvesting.  I'm not convinced that those problems are
insoluble, in large part because style sheets are generally treated as
reusable and cacheable components.  There's a cost, but I don't think
it's that drastic.

>(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.)

Given the wide variety of uses to which URIs are now put, I think you're
wise to use a different addressing mechanism for the demonstration.


[1] - http://people.opera.com/howcome/2000/css3/clink-nov-6.html
[2] - http://www.xml.com/pub/a/2000/04/19/opera/index.html

-- 
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com -- http://monasticxml.org



More information about the xml-hypertext mailing list