Does co-linking measure up?

Bob DuCharme brings news of a technology out of Brazil called co-linking. Through scripting, it provides two XLinkish features: one-to-many links (in the form of a menu that comes up when you click) and third-party links (in the form of reader-insertable links). Interesting! The menu showing the multiple link destinations is exactly how I always pictured it working in XLink, and it’s something I’ve often wished had broken out as a popular feature.

How does co-linking stack up to the rules I proposed in my third-party linking manifesto below?

• By default, third-party links SHOULD NOT be added by a presentation system. Users MUST be able to opt out of being presented with them. Creators of content MUST be able to opt out of having third-party links applied to their content. It appears that you have to publish co-linkable content with their technology explicitly enabled, so consent seems to be involved by the very nature of the system.
• Third-party links MUST, by default, be presented differently from originally authored links. This distinction MUST persist in all forms of the content (formatted on a screen, spoken, view-source…). I don’t know, but I’m guessing they could allow for this if a customer wanted it.
• The origin of various third-party links created by different third parties SHOULD be distinguished from each other, ideally indicating their authorship or provenance and a way to contact the link author. The system does seem to capture this as metadata; they ask you to provide your name and email address when you add a link. Presumably this can be used in the display somehow.
• Commercially sponsored third-party links MUST, in addition, be separately controllable from other third-party links in the manners listed above. Also unknown, but it could just be another kind of metadata that hopefully makes it all the way through to the presentation.

All in all, it seems pretty non-evil. Since it’s a proprietary way to express the linking information, I would think it gives a lot of control over how the capability gets deployed — you probably wouldn’t want to give J. Random Reader Guy co-linking rights, unless you want to build a Wikipedia-style community with “controversy management” and all the rest of it. For XLink or any similar standards-based technology to achieve that level of control, it would have to get more sophisticated (read: even more heavyweight than it already is). But it would be interesting if the developers of co-linking were to offer an XLink import/export option…

Lauren!

Welcome to Sun, Lauren!

I’m pleased to get the chance to work with her more closely than ever before. This is a lady who has a lot of talents in the technical, organizational, and political realms. I used to call her the W3C DOMinatrix but I’m not sure she’s a fan of that name… (When it comes to specification work, a little whip-cracking is to be expected, no?)

More XPointer activity

I didn’t expect to be posting so much about linking-and-pointing, but hey, when there’s news, might as well share it… I may have to create a Linking category for posts if this keeps up.

I just saw a note from Bryan Thompson on the www-xml-linking-comments list, detailing his Java-based implementation experience with XPointer in the cweb project on SourceForge. This project is defined as “A framework for building, deploying and managing well-described REST-ful Web services, including REST-ful Web Services realizations for RSS, XML Topic Maps, Structured Arguments, and Workflow.”

It appears as though this project has chosen a scope for its XPointer work that’s similar to Oleg Tkachenko’s work I mentioned below. It puts a premium on supporting extensibility of schemes, and also covers the non-W3C-oriented xpath() scheme and others:

Overall, the extensibility of the XPointer Framework has been the most interesting and powerful feature. We have developed non-W3C schemes for xpath(), RDF, and are exploring schemes for RSS/Atom.

Neato! All the moving parts of XPointer (except for the xpointer() scheme itself, which isn’t a W3C Recommendation) are starting to exude that special scent of success. Maybe if Google’s AutoLink feature gets sophisticated enough, it’ll even need xpointer()…

Third-party linking manifesto

Ben Hyde, mentioned just below, has a post yanking on the Google Toolbar feature, called AutoLink, which offers what XLink called “third-party links” (though perhaps the Google presentation model might not result in a pure example of a true third-party or out-of-line link; I’m not sure, not having tried it). He’s not the only one; Dave Winer systematically rips apart the feature.

I think Dave’s criticisms are valid, though I think it’s eminently possible to follow implicit guidelines he provides. Some people have always had discomfort about out-of-line linking and the potential for confusion and even legal liability problems. I think the presentation context (in the larger sense, as well as the specific XLink sense) makes a big difference here. It should always be possible to distinguish author-provided links from third-party links, and if doing a View Source or a copy-and-paste obscures or removes the provenance of links, that’s a serious problem. We have an old and venerable system of distinguishing “foreign” content in quotations; we need the same for links.

Here’s an example of what seems to be a relatively unobtrusive, unconfusing addition of links to content authored by someone else. The latest version of the Trillian messaging/chat client has something called Instant Lookup, which I think I like (I’ve only been using this version for about a week). As you and your messaging partner(s) type, the log puts a dotted line under words and phrases that have a Wikipedia entry. When you hover your pointer over the word, the entry loads (pretty quickly) and then displays. It’s obvious that the people exchanging the messages didn’t insert the links and it’s obvious where the entry content comes from, so any problem you might have with that content can be taken up with the appropriate people — and, of course, you can turn the feature off entirely if you like.

Another kind of “third-party” linking is trackback and pingback systems. These are opt-in systems that typically demarcate original author content and added-later content in an obvious way.

(Moving from a scare-quote version of third-party linking to the entirely metaphorical, there’s the ability of blog authors to update a post to reflect activity going on elsewhere as a result of the original version of the post. When I first started reading blogs (aside: why is there no single word for a “blog reader” like there is for “blog writer”? how about “bloggee”?), I was entranced by the magical ability of blog posts written by different people to get entangled from a linking perspective, seeming to leap forward in time to comment on each other and to comment on such commenting.)

We saw that the XLink model of “third-party links for all” didn’t exactly light the world on fire. I seem to recall that there was a proprietary product that offered roughly the same capability around the same time, but I can’t recall the name and searching isn’t helping to jog my memory. It didn’t do very well, either. However, it seems that there’s a new spate of client-side systems that add links in this fashion and at least some of them may stick.

What if we were to come up with a crisp manifesto for the design and usage of third-party links and their presentation systems, and then use it to hold the developers of such systems to account? Defining “third-party links” as “links added by any party other than the original author of the content”, and leaning heavily on the indispensible RFC 2119 :-), we might have something like this:

• By default, third-party links SHOULD NOT be added by a presentation system. Users MUST be able to opt out of being presented with them. Creators of content MUST be able to opt out of having third-party links applied to their content.
• Third-party links MUST, by default, be presented differently from originally authored links. This distinction MUST persist in all forms of the content (formatted on a screen, spoken, view-source…).
• The origin of various third-party links created by different third parties SHOULD be distinguished from each other, ideally indicating their authorship or provenance and a way to contact the link author.
• Commercially sponsored third-party links MUST, in addition, be separately controllable from other third-party links in the manners listed above.

Editorial nanites

Speaking of typos… Ben Hyde, whose Ascription is an Anathema to any Enthusiasm blog appears over on my blogroll, has added a clever feature. He knows he tends to make a lot of typos in his posts, so he has added a feature to let you, the reader, help him correct them.

He and I had been talking a few months ago about his wish for something to just swarm over his text and fix it — which I dubbed editorial nanites. Since I’ve always had the editing bug (so to speak), I offered to do an editing pass any time he liked. Now anyone with the same affliction that I have can play along!

Typing styles as fingerprints

I can believe this:

The way you type is as unique as your eye colour or speech patterns and can be used instead of a password to protect your computer, researchers at Louisiana Tech and Penn State say.

The technique focuses on keystroke timing, but if it also analyzed typo patterns, I imagine the technique could be even more accurate (though of course much larger samples would be required). Whenever I intend to type “elephant”, half the time my first attempt is spelled “element”. It’s a finger macro! (Uh, not this kind…)

Shameless plug

My father-in-law is (mostly) retired, but creates beautiful jewelry made of silver and crystal for fun and profit. If you’re looking for a gift for a person who would appreciate earrings or a necklace or a bracelet (a sweetheart? bridesmaids?), check out Leon’s Stitch Crafts on eBay. He can also create customized “name bracelets” in English and Hebrew.

Chandelier earrings by Leon’s Stitch Crafts

Some attractors are stranger than others

Want a weekend stitching project? Do a little crocheting (well, okay, a lot) with a chaotic attitude, and you could even win some bubbly:

Dr Hinke Osinga and Professor Bernd Krauskopf, of Bristol University’s engineering mathematics department, used 25,511 crochet stitches to represent the Lorenz equations.

The equations describe the nature of chaotic systems – such as the weather or a turbulent river.

The academics are offering a bottle of champagne to anyone who cares to follow the pattern published in the journal Mathematics Intelligencer.

Thanks to Bob DuCharme for the pointer.

Siapo stitching project

I marvel at the real cross-stitch weenies who keep several projects going at once and attack them in 10-hour rounds. I tend to be more single-minded and only have limited time and attention for stitching, so I like to barrel through one project at a time. However, since I constantly feel the (entirely self-imposed) pressure to produce something fancy for the XML conference at the end of the year, I may be forced to begin timesharing soon.

Having completed a big XML-themed stitching project in time for XML 2004, I took a break in December. (I’m playing around with some ideas for an XML 2005 project, but I’m not ready to share those explorations yet.) In the meantime, with the prospect of lots of upcoming plane travel — where I do quite a bit of my stitching — I knew I had to get something else going. So I started this new pattern in January.

Siapo stitching project as of 9 February 2005

It’s an adaptation of designs and symbols traditionally painted on Samoan “siapo cloth” (like Hawaiian tapa cloth), though many of the symbols aren’t visible above just yet. I bought the pattern, along with a number of other south-Pacific-themed ones, on a trip back to Hawaii maybe a dozen years ago when I first ventured into stitching. I got it at the old Ben Franklin store in Hawaii Kai; I don’t think it’s there anymore and thought the company had gone out of business, but was delighted to see one in Redmond a couple of weeks ago. This listing shows that there are still quite a few in Hawaii, too. Cool!

The pace and “feel” of each project I’ve done have been quite distinct. I chose this one as a relaxing counterpoint to the previous one. Here are the most prominent features of this one:

• Monochromatic floss. It’s all black; there’s no switching of colors, which makes it easy but a bit more boring. I do like the resulting stark figure/ground contrast, though. The DocBook project used 25 different blues, greens, and greys plus black, and it was quite pleasurable to work with that palette but some of the colors were hard to distinguish from each other.
• Off-white fabric. I chose antique white Aida to give it a bit of that tapa-cloth look; something slubby might have been even better. It’s a relief to be working on a project that doesn’t depend on perfectly clean hands at all times (you’re supposed to wash your work at the end to get the finger oils out of it but I never do). I could even probably give it a “tea bath” at the end to increase the verisimilitude. Hey, and this means I probably don’t have to protect it so carefully when a flight attendant passes a drink over to the guy sitting next to me on the plane — a Coke bath would work just as well!
• 18-count. I could have chosen any “granularity” (point size?) but chose something tiny so that it would look nice and fine. Unfortunately, it’s giving my incipient Over-40-Eyes Syndrome a tough time, and I’m finding that I really need my reading glasses. Next time 14-ct for sure…
• Not designed by me. A nice break! The designer used a dot as the sole stitch-color symbol, and she obviously filled in every single one by hand — yikes. For some reason it reminds me of a music theory homework assignment I got in high school, where we had to compose a piece and do the score in pen (this was in the pre-music software days). I was late getting my assignment ready and did it in blessedly erasable pencil — then ran to the library and Xeroxed its final form. Voila, “pen” marks.
• Not digitized into PCstitch. Thus, I don’t have precise numbers on how many stitches there are, and for the first time in a couple of years I didn’t start with a rough notion of how many hours it would take me. Like a progress dialog box for some kind of streaming process — no percentage bars here! — I’ll just chug away till I’m done.
• Radially symmetric (palindromic?). Only one half of the pattern is provided; to do the other half, you flip the pattern around and start again. The whole thing is supposed to be vertically oriented, but the top half of the pattern is provided in counter-clockwise-rotated form. So the picture above technically should be rotated 90 degrees to the right, but I’m going to persist in thinking of it as horizontal until I’m done stitching. What’s extra-weird about all this is that normally my stitches are “bottom right to top left primary”, meaning that the top stitches in all cases stretch in that direction, but because of the flipping, this piece will ultimately be displayed as “bottom left to top right primary”. That sort of bothers me for some reason. [Uh, because you're anal-retentive? -ed. Oh, shut up.]
• Two strands. The DocBook project, which was on 14-ct, used three strands of floss for all the stitches. On this 18-ct fabric, two strands seem to give just enough coverage. Most of the time I’ve been threading a single strand and then doubling it up, which gives a whole different experience from threading two strands through and leaving a “tail” — the needle becomes sort of intrinsically connected to the piece and there’s no way you can lose it, but you’ll have to snip the thread to break the connection if you make any mistake that requires serious unpicking.

Whew. That’s enough waxing philosophical about stitching for now…

A marginally pointier (and linkier) world

I’ve been busy arranging to move all my atom-based possessions from one end of the continental U.S. to the other (actually, most of them will get cached for a while). Moving the bit-based possessions was a much cleaner experience — in every sense.

So this news tidbit is slightly stale. On January 20, Oleg Tkachenko announced something called the Mvp.Xml library, a set of C# modules on SourceForge that implement XInclude and XPointer.

My first thought on glancing at the announcement was “Hmm, I bet it just covers the XPointer framework.” But it turns out they’ve done the schemes too, going as far as providing xpath1() support as defined by Simon St. Laurent, and the XPath-based portions of xpointer() support.

I was surprised and pleased to see this. The main use case here is XInclude inclusion, so it’s fair enough that the wizzier features of the xpointer() scheme — which were driven primarily by a “the user clicks and drags across a non-well-formed chunk of content to highlight or annotate it” use case — aren’t covered here. Many moons ago during the original XPointer work (and even earlier, when the whole ball of wax was called XLL), I had vociferously argued that the advanced features should be separated out into a higher conformance level, and I remember thinking that Simon’s xpath1() spec was a good idea when it came out.

I always perk up when news of XPointer (or XLink) comes along. I’ve long been resigned to the idea that we didn’t exactly hit a design sweet spot on either of these. (In the less-stale news category, a new W3C note edited by Norm Walsh has just come out recommending some simple changes to XLink that would “sweeten” it a bit; I think the idea to make xlink:type="simple" an application-level default is an obvious winner.)

Perhaps the story on these technologies isn’t over, particularly now that basic XML support is nearly everywhere. Marginal improvements and increases in support might provide enough of a boost, and it’s nice to see that there are some honest-to-goodness real boosters out there, like Oleg (and like the xlinkit folks and at least some of the designers of XBRL, who are XLink fans).

XPointer was ultimately refactored enough (the invention of the “framework”) to give its lower conformance levels some success. It might be fun to go back and really refactor XLink, this time with a clear view of the modern use cases.

p.s. In poking around on the subject of xpath1(), I came across this post of Oleg’s from last year. Booster, indeed — thanks for spearheading the project (and for the kind words)! But I notice his prediction of when XInclude would become a final W3C Recommendation was off by about 21 months…

UPDATE: I had noticed that David Megginson made a case on xml-dev last month for the XLink simplification noted above, and almost mentioned him as the genesis for the idea as it appears in the W3C Note. But realizing that this was merely an assumption and not wanting to take the time to look into it, I dropped the mention. But now I see that Tim Bray mentions David’s new blog and a particular early post that explains the (lack of) connection — apparently it was a coincidence! That sure makes it seem like an idea whose time has come.

As a new blogger myself it feels weird to be saying this, but, David, welcome to the blogosphere!