The DocBook TC has a long-standing action item to add more "universal"
linking to DocBook. At the moment, there are a small handful of
linking elements in DocBook, but there's considerable pressure to
extending linking semantics to more elements. Let's say "all inlines"
for the sake of something to talk about. This item has been open since
1997 and the TC has largely left it open so that XLink could stabilize
and we could use that. XLink came out a while ago, but I've personally
continued to drag my feet because I've been waiting for XPointer to
stabilize. (I recognize that XLink makes sense without XPointer, but...)

With the publication of the XPointer framework and element schemes, I
think XPointer is finally in pretty good shape. And I'm ready to
propose that DocBook adopt XLink for linking semantics, except that
now it looks like the whole enterprise may collapse under its own
complexity. Sigh. (I can say that about more things than I care to
admit these days, but that's a topic for another post.)

So what should we do about XLink? I see a few alternatives:

1. Give up ("we don't want your stinking application"). This choice
   says that a universal linking language, the ability to write
   applications that unambiguously (and without heuristics) recognize
   links in vocabularies about which they do not have domain-specific
   knowledge, is not useful or interesting enough for the web to
   support.

   Practically, this means DocBook can define any linking attribute it
   wants (probably url for compatibility with the existing ulink tag).
   DocBook defines the linking semantics, or provides its own markup
   for specifying them.

2. Give up ("XHTML sets the defacto standard"). This choice says that
   we can approximate a universal linking language by saying any
   attribute named "href" is likely to be a link. That's the best we
   can do.

   This means DocBook uses 'href' and defines its link semantics to be
   "like HTML".

3. Use XLink ("XLink is a Recommendation, darn it"). This choice says
   that for a large class of applications that, alas, does not include
   XHTML, the linking vocabulary defined by XLink is about right. The
   penalty for using attributes only is that you have to namespace qualify
   them. The benefit is that you don't have hairy content model
   problems.

4. Fix XLink by adding an "xlink:href-name" attribute that allows
   HTML to say that the 'href' attribute (unqualified!) is the
   xlink:href attribute and has the semantics defined by the appropriate
   XLink attributes.

   This means DocBook can use 'url' and also use XLink. Cool.

5. Fix XLink by adding "xlink:XXX-name" attributes so that all of the
   XLink linking attributes can be renamed on a per-element basis (and
   by extension do not have to be in the XLink namespace).

6. Fix XLink by starting over and using elements instead of attributes.

7. Fix XLink by starting over and ... doing something else.

So. There. Now, what do I think when I think about this? I think 1 and
2 are disappointing. I could live with 3, but I'd like to know I
wasn't alone before I started off in that direction. I think 4 is
reasonable, and I'd be happy to support it if we could get consensus
that it's the minimum needed to declare victory. I could live with 5,
too, though I think it's a bit heavy weight. (Then again, isn't
everything now-a-days?...bad norm, stop thinking things like that.)

The story so far: 4 looks like a reasonable position to start
advocating in the hopes of gaining consensus.

Then someone reminds me of this HTML construct:

  <a href="someuri" longdesc="someotheruri"> Click Me!!!</a>

and I realize that even 5 isn't going to solve all of the XHTML
problems. This also means that 2 doesn't work, unless we're going to
let XHTML define two global, unqualified attribute names.

We're back to 1, 6, or 7.

But wait, perhaps the XHTML community could be convinced that the
functionality of the longdesc attribute could be designed differently,
using additional element markup, for example?

I dunno. Can XLink be fixed?

                                        Be seeing you,
                                          norm

-- 
Norman.Walsh@[...].COM    | On the other hand, you have different fingers.
XML Standards Architect |
Sun Microsystems, Inc.  | 

-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org> , an
initiative of OASIS <http://www.oasis-open.org> 

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>