Cart
[Home] [By Thread] [By Date] [Recent Entries]
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@s...> >To: xml-dev@l... >Subject: RE: 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
|
