OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] SkunkLink: a skunkworks XML linking proposal

[ 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 

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 
>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 
>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 
><para>Check <link>http://www.cnn.com/WEATHER</link> before you fly to Los 
>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*. 


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS