[
Lists Home |
Date Index |
Thread Index
]
There were a lot of serious complaints about XLink because it requires
attribute prefixes. I can't imagine the HTML folks favorably regarding the
URI-as-content idea.
But I see your point. You could just as well have said:
<para>Check <link _="http://www.cnn.com/WEATHER"; /> before you fly to Los
Angeles.</para>
It still provides essentially one piece of information: the target URI.
I also must disagree with your point. I don't think acceptance of any
particular linking technology has been greatly impeded by dispute over what
information should be captured by the link. Most of the disputes I see are
about the surface minutia: Elements vs Attributes; Namespaces; mandated GIs
vs Choose-your-own-GIs.
I submit that this is the really hard part: coming up with an easy to use
and widely attractive _syntax_ for linking.
-Wayne Steele
>From: Bob DuCharme <bobdc@snee.com>
>To: xml-dev@lists.xml.org
>Subject: RE: [xml-dev] SkunkLink: a skunkworks XML linking proposal
>Date: Wed, 08 Jan 2003 23:49:58 -0500
>
>My two cents on SkunkLink and the potential future directions of linking in
>XML, which recapitulates something I said in the Linking Town Hall in
>Baltimore:
>
>An important recurring theme in this thread has been the need for
>modularization in linking markup, and I hope that this idea doesn't fade
>away.
>
>At its core, a link only needs a single piece of information: the locator
>for a remote resource. If that's all there is, the resource holding it is
>the implied other end of the relationship being expressed, and you have a
>link:
>
><para>Check <link>http://www.cnn.com/WEATHER</link> before you fly to Los
>Angeles.</para>
>
>I'll admit, before Len points it out, that for better or worse this
>particular URI itself carries some additional semantic information; you
>don't have to follow it to get an idea of where it goes. Still, of all the
>people saying "I've stripped down linking to its essentials," I'm shooting
>for the "most stripped-down" prize.
>
>Now, most will agree, if not insist, that a linking architecture needs more
>than just locators. It needs a few more things. What things? I have my own
>opinion, which I will keep to myself for now. Micah has published his idea
>of what they are (three of xlink:show's five values: replace, embed, and
>none. Just kidding.) Simon has alluded to a work in progress. What I'd
>really like to see is that once everyone submits their ideas about the most
>important metadata to carry with a link, we group this metadata into
>functional categories and then raise the discourse to a level that
>addresses those categories, particularly their dependency relationships.
>That would be the beginnings of a real linking architecture, and something
>that could be implemented as a modular spec that could more easily serve a
>lot of needs without overwhelming anyone. (Wouldn't it have been great if
>W3C Schema had done that?)
>
>
>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)
>
_________________________________________________________________
MSN 8: advanced junk mail protection and 2 months FREE*.
http://join.msn.com/?page=features/junkmail
|
