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!
