A Common Ground for XML Linking

SkunkLink: The SLink language provides a data model and syntax for XML linking, suitable for use in XHTML 2.0 and related languages.


Is anyone thinking about using this in Echo/Atom/Pie?

Posted by mdubinko at


I like SkunkLink. It is "The simplest thing that could possibly work."

Looking at Echo/Atom/Pie I see a lot of URIs floating about and see alternatives:

1. Keep stuffing then into their own elements, with sometimes different names, ala author.url, entry.link, entry.id.

2. Use XLink

3. Use SkunkLink

Now choice #1 is fine. If you want to consider making E/A/P easier to process by tools that natively don't understand the format but are looking for links, like a search engine, then you might consider adopting #2 or #3. That's not mandatory, but it may be worth considering. Having looked at XLink for use in RESTLog and then rejecting it for what I consider unneeded complexity, I have to say my preference would be for SkinkLink.

Posted by Joe at

I'm not sure how much SkunkLink is relevant to Pea.  SkunkLink defines two limited types of link, "go there" and "include here".  These types are the common ones in hypertext document bodies, but they're limited in purpose.  Even documents (headers and RDDL, for example) have several other types of links as well.

XLink wants one to explicitly label the link types and roles, which explains its additional complexity.

Pea has/needs many types of URIs.  Surely they can't be classified only as "go there" and "include here" links (no?).  Right now, the types appear to be defined in the documentation, and the roles seem to be split between documentation (fixed roles) and additional properties.

Whether or not the link classification is in-band or out-of-band seems to be the real discussion in Atom Schemata

Posted by Ken MacLeod at


Re: "Surely they can't be classified only as "go there" and "include here" links (no?)"

In the big picture, no, there's all kinds of flavors of links, not just two. Thus there are lots of ways of forming links besides href and src. But of the types of links that generic processors (search engines, etc.) care about, a strong case can be made that the 80/20 point is those two attributes y nada mas.

For all those link types that generic processors won't care about, special knowledge of the XML vocabulary is already required, so there's little point of trying to force-fit XLink or whatever. -m

Posted by mdubinko at

If we'd equate xml:href with the ref attribute from the ExtensibilityFramework; not "go there" but "is there" or "has this URI", then I think SkunkLink is sufficient for Pea. F.e.:

<generator xml:href="http://www.example.com/blogamatic.cgi">
  <name>John's Blogamatic</name>
</generator>

Posted by Sjoerd Visscher at

Micah, lets turn it around then.  Why not xml:uri?  That'd be 100%.  I hope you disagree with that idea, because the definitions, as-is, of href and src are important parts of their usage.  Many of the URIs in an Atom XML instance (note I'm not saying "document") are not intended to be traversed or retrieved (even if they use the http: scheme).

Sjoerd, you need to talk to Micah about that, as "An arc-type of href indicates the intention that, when the link is traversed at the user's option, the presentation context will be changed to the ending (sub-)resource."  Using 'href' for <id> seems... inappropriate.

Posted by Ken MacLeod at

Add your comment












Nav Bar