Alex Milowski asks on Twitter about my thoughts on Skunklink, now a decade old.
Linking has long been thought one of the cornerstones of the web, and thereby a key part of XML and related syntaxes. It’s also been frustratingly difficult to get right. XLink in particular once showed great promise, but when it came down to concrete syntax, didn’t get very far. My thinking at the time is still well-reflected in what is, to my knowledge, the only fiction ever published on XML.com: A Hyperlink Offering. That story ends on a hopeful note, and a decade out, I’m still hoping.
For what it purports to do, Skunklink still seems like a good solution to me. It’s easy to explain. The notion of encoding the author’s intent, then letting devices work out the details, possibly with the aid of stylesheets and other such tools, is the right way to tackle this kind of a problem. Smaller specifications like SkunkLink would be a welcome breath of fresh air.
But a bigger question lurks behind the scenes: that of requirements. Does the world need a vocabulary-independent linking mechanism? The empirical answer is clearly ‘no’ since existing approaches have not gained anything like widespread use, and only a few voices in the wilderness even see this as a problem. In fact, HTML5 has gone in quite the opposite direction, rejecting the notion of even a vocabulary-independent syntax, to say nothing of higher layers like intent. I have to admit this mystifies me.
That said, it seems like the attribute name ‘href’ has done pretty well in representing intended hyperlinks. The name ‘src’ not quite as well. I still consider it best practice to use these names instead of making something else up.
What do you think? -m
I could not agree more! I think XML needs to help derived formats by providing the option to use those hypermedia affordances. Don’t need ’em? Don’t use ’em – invent your own. But at least give devs a reliable way to access the web from their xml. Who knows? Maybe browser makers would give xml:href and xml:src, xml:type some love, and XML formats would be able to load code on demand where the browser only needs to provide network access. Thanks !
Xlink solved a wrong problem; back then we really needed a way to describe existing vocabularies, to say, to make a link you take the ID of the recipe element, prepend http://www.example.org/ and the category attribute of the containing recipe-list element, and then append / to get, e.g. http://www.example.org/smearable-sauces/pumpkin-and-bleach/
Instead, Xlink requires authors to change their XML to use its attributes. But if you are going to do that, you start to wonder about converting it to HTML anyway.
Today, html:href goes a long way – in practice about as far as most people ever went with XLink, and with less hassle.
My problem with linking primatives in XML which are vocabulary agnostic, is “what do they mean” ? In HTML an means “click here and get to another page. But what about XML ? If you dont know the vocabulary, which means you dont know the *application* what is a pure XML processor supposed to do with a “link” ? It could mean many things
* Link to embeded content -> like and external parsed entitiy
–> Go fetch this content and *embed* it here
* Link to a related topic -> This thingy over there is realated …
but does that doesnt necessarily mean “make a clickable link in an app”
* Link to graph related content
–> XML is hierarchial. But if you want to represent a graph you need to define shared nodes once and reference them from multiple places (like id/idref). Links could span documents but not mean “go there”
* RDF kind of links, similar to the graph concept. “This thinging belongs in this RDF graph”.
These are all very different meanings and if interpreted by an application would imply different behavior.
So in my mind, sans a vocabulary and hence sans any concept of an ‘application’ the meaning of a singular “link” in XML is worse then useless. Why worse ? Because if you ask 10 people what it means you’ll get 20 answers. So to solve this we need a much more complicated set of thingies that say “This is a graph edge link” , “This is embedded content required to finish parsing this document” , “This should be shown as a user-agent link” , “This is a footnote, but its not really important” … and on and on. As this list grows what we are actually doing is defining a vocabulary, and possibly an application.
By the time that done the links are tied to the vocabular (explicit or implicit).
So if we want all these cool linky things … we should define a link vocabulary that is interminable with other vocabularies so it can be shared. Which, I suppose, is what XLink did.
Thats my take as to why links don’t belong or work at a “pure xml” level.
They need a context to make sense out of them.
-David