linkbase brainstorming [xlinkScope-23]

XML 2002 included a Hypertext Town Hall which I consider to have been
one of the more fruitful panels on which I've participated.  I've been
thinking about and working in XML hypertext for a long time, but that
Town Hall crystallized some ideas that had been percolating for a while.

I think Micah Dubinko's SkunkLink covers the fundamentals for inline
linking:
http://dubinko.info/writing/skunklink/

Having that problem mostly solved makes it easier to focus exclusively
on linkbases, which seem to me a very different set of problems.  Tim
Bray once said:
http://lists.w3.org/Archives/Public/www-tag/2002Oct/0087.html

>I reviewed the XLink spec, and I thought about how I'd go about 
>designing markup for multi-ended and out-of-band links, and I thought 
>XLink presented a pretty compelling design for how you'd do those 
>things.

I don't find XLink anywhere near "a pretty compelling design".  Tim
also said:
>I think disagreement should be accompanied by examples: "here's a
>better way to do a multi-ended/out-of-band/metadata-loaded hyperlink,
>and here's why it's better."

It takes a long time to do that, and I'm not nearly done yet, but some
early efforts of mine are available at:
http://simonstl.com/projects/vellum/

Very Extensible Linking Language Unafraid of Markup (VELLUM) accepts a
greater verbosity level in exchange for much greater extensibility and
freedom from the limitations of URI structure.  It doesn't yet define
all the role and behavior information of XLink, but the foundation
structures can carry that weight easily.

I don't consider my current structures the final word on how to create
out-of-line links, but I do think it's worth considering the benefits
of an element-based syntax rather than one which insists on cramming
complex information into attribute values.  This approach:

* makes it a lot easier to create reusable target descriptions with
friendlier names than URIs can offer, though it still lets developers
use URIs and URI references directly if they choose.  

* makes it possible to deal with the full range of content-negotiation
possibilities and specify representations rather than hoping that the
resource will be kind.  

* provides a much less constricted space for identifying document
fragments, one where the schemes created by XPointer can operate without
the constraints of its syntactic framework.

Comments, suggestions, and criticisms are welcome.  This is only an
early draft!

-- 
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com -- http://monasticxml.org

Received on Thursday, 16 January 2003 09:17:22 UTC