Let’s say that, from a single point in this document, I want to refer you to several things at once. Modeling this one-to-many link and marking it up is simple enough with XML: you create a container element that holds other elements, each representing a link destination. But what do you do with that markup? How do you turn it into a choice of link destinations to offer to an end user?

One old-fashioned option is so simple that many won’t even think of it as a one-to-many link: you add a layer of indirection by pointing to a single page that has the links you want. For example, “If you’re interested in Unicode’s role in XML, many good references are available.”

The most obvious user-interface widget for a more direct one-to-many link is a pop-up menu. Implementing it on a web page pulls you into the classic platform/browser-app/browser-release quicksand quickly enough, but it’s still fun to play with. I took a nice JavaScript library and used it to create a prototype of one-to-many linking from an XML document displayed in a browser, and that came out pretty nicely, depending on your platform/browser/release combination; I also explained the workings of the XSLT underneath in an XML.com column.

Some developers, though thankfully not too many, seek a compromise between these last two ideas by popping up a new browser window with a small document listing the link destinations, like in this reference the W3C Schema Recommendations. With the browser’s navigation bar, menu, and other optional decorations removed, it looks a bit like a pop-up menu, but it’s still a new browser window, and any new browser window on a screen should be there because the user asked for it, not because a developer wanted it there. In this paragraph’s link I made the window small to look more like a pop-up menu, but if you follow one of its links, it puts the target resource in the same little window. You could tackle this using even more Javascript, but again… quicksand.

One nice, simple trick I’ve been seeing combines HTML with simple punctuation to group the link destinations: a parenthesized, delimited list of HTML a elements. For example, “Earlier this month, several new RDF Working Drafts (1, 2, 3, 4, 5, 6) were released.” I’ve seen Jon Udell do this with commas as the delimiters, as I did here, and I’ve seen Slashdot use pipe symbols. Either way, despite its lack of whiz-bang UI flash (or, more likely, because of it), it works on every browser, and an XSLT transformation from any higher-level XML-based representation of one-to-many links into this format is simple. You could even add more sophisticated linking features to this interface by setting the numbers in different colors to show link types or by adding title attributes to the numbers’ a links to show metadata in mouse-over popups, as I did with the RDF example.

Has anyone seen other variations on this use of delimited lists as one-to-many links? What’s the earliest use you’ve seen of this?

Because linking has always been so important to the web, many people looked forward to the W3C’s XLink specification because of its promise of delivering the next generation of linking. While it did show ways to model one-to-many links with extended links, it didn’t show ways to implement them—in fact, it intentionally avoided this to keep the data structures it described high-level enough so that they could be implemented on a variety of platforms. The trouble was, practically no one implemented them, so people still wonder: how should they be implemented? You don’t need advanced technology (as I’ve written here before, Frank Shepard was doing it in the nineteenth century, and Bibles were doing it long before that), but part of the fun of new technology is the new possibilities it opens up. It’s only natural to wonder what new options new user interface developments will offer us for representing one-to-many links.

How have you seen one-to-many links implemented?

Related link: http://lists.w3.org/Archives/Public/www-international/2003JulSep/0213

The last few weeks have seen a dismaying upturn in the number of semi-public institutions which seem to out to make a buck rather than a contribution, risking the contributions they’ve alread made.

ISO has the potential to cause the largest trainwreck, with plans to require licensing fees from those who use their language codes (ISO 639), country codes (ISO 3166), and currency codes (ISO 4127). The W3C has posted a letter to ISO, noting that:

These and similar codes are widely used on the Web. In particular the language and country codes are of direct interest to W3C and the users of W3C Recommendations in the context of HTTP, HTML and XML and various other technologies. Language and country codes currently provide a single, standard way of identifying languages (and locales) throughout the Web. Multilingual Web sites and Web pages, as well as internationalization and localization features, would be particularly affected.

Any charges for the use of these standards are going to lead to fragmentation, delay in deployment, and in effect a lack of standardization. In particular, those users who depend upon multi-lingual or non-English language services will suffer.

It appears that ANSI (the US member body for ISO is already at work collecting these royalties, as this exchange suggests. Warnings have gone up on the ISO 3166 site as well.

Robin Cover has an excellent summary page of the ISO situation and responses to it.

Meanwhile, another highly-respected organization which has made substantial contributions to the Web seems to have gone fishing for loot as well. OCLC, the Online Computer Library Center, one of the lead drivers behind Dublin Core, a vocabulary at the heart of many RDF projects, is suing the Library Hotel for daring to structure a library around the Dewey Decimal System, which was created in 1874. It’s a trademark case, so things like patent and copyright expiration don’t apply, but it’s hardly encouraging to see an organization so critical to the information infrastructures of the world - not just the Web - “seeking damages of three times the profits the hotel has made since it opened”. Trademark law does require defending the trademark, sure, but this? Come on.

I’ve been a critic of the W3C’s structure for a long time now, having doubts about the nature of vendor consortia. On these kinds of issues, however, the W3C seems to be well ahead of its peers. While the process of creating many W3C specifications may remain veiled in mystery, the specifications themselves are open for anyone to implement, free of charge - and the W3C seems intent on keeping it that way, even in the face of recent patent lunacy.

The larger problem this illustrates isn’t the greedy nature of everyone, but rather the difficulties of trust in a world where organizations are underfunded and expected to scramble for dollars. Building organizations which are intended to promote the sharing of resources requires an independent source of funds. Otherwise, organizations will end up placing tolls on their results, impeding the very sharing they were set up to create.

Any thoughts on how to encourage sharing rather than toll booths?

Related link: http://seanmcgrath.blogspot.com/archives/2003_08_31_seanmcgrath_archive.html#106…

I’ve been thinking about how RSS item elements aren’t quite links, but can be turned into links with very little trouble, such as conversion to HTML or loading into a news aggregator. Before then, they identify something to link to, but nothing to link from. It’s up to the user of the RSS feed to put that linking information into a context that turns them into links.

And as linking information goes, I love RSS items, because each comes with a pack of metadata about its potential link destination, and the more that people can know about a link before traversing it, the more value that link has. While competing W3C Working Groups argued about whether link metadata should be stored in attributes, because that’s what people are used to from HTML, or in subelements, because you can store so much more metadata, the growing success of RSS proved the latter camp to be correct. Inside of an RSS item element, you have one child element with a URL about a resource on the web and other child elements with metadata about that resource. The increasing use of the “dc:” prefix is another sign of progress that we shouldn’t take for granted—more and more of this metadata actually conforms to a standard!

A recent weblog posting by Sean McGrath, who I’ve known since XML was a four-letter word, made an excellent suggestion about a source for even more metadata for links to weblogs. It’s another indication of the excitement around RSS: the existence of this simple format for a new class of easily shared (meta!)data keeps inspiring new ideas for applications—especially linking applications.

Do you know of any new kinds of applications being built around RSS?

Related link: http://www.eweek.com/print_article/0,3668,a=45363,00.asp

The recent e-Week article from Darryl Taft mentioned that MS has been hiring up industry thought leaders. I’m happy to say that Glen Daniels has joined us (Sonic), despite him being on Don Box’s “hardball recruiting list”

Among many other things, Glen will be playing a strategic role in heading up our standards and consortia involvement

Sonic’s growth over the past few years from being a pure JMS vendor to a pioneer of standards based integration in the increasingly popular Enterprise Service Bus trend will certainly provide some fertile ground for Glen to work in.

Dave