Further XLink Concerns

[Please note - this is a crosspost to www-xml-linking-comments and
xlxp-dev.  Unless you want your comments to appear on both lists, please do
NOT hit 'reply all'.]

Since I posted my last comments - and visited the archive site again (at
http://lists.w3.org/Archives/Public/www-xml-linking-comments/) - I'm
wondering why XPointer seems to be the topic on most activity, both in
these few comments and in the discussions I had at XTech.

After thinking about it for a while, I'm concerned that XPointer is getting
more attention because it's much easier to get a grasp on.  While XPointer
is contentious, and everyone wants their own pieces put into XPointer,
XLink's many facets seem to get a different interpretation from everyone
who claims to understand them and blank stares from the many who don't.
While XPointer is technically challenging, its fundamental project -
describing fragments - isn't that difficult to grasp.  XLink, on the other
hand, is mysterious.

I'll quote from one of my fellow XML book authors, describing a simple
out-of-line link from X to Z:

---------------------------------------------------

A koan in hiding

Careful readers may have picked up on the built-in contradiction lurking in
the preceding discussion: If there is no X in the X-to-Z link, then what is
the 'thing' that points to Z?  And if the 'thing' does indeed point to Z,
doesn't it, well, participate in the link?  And if so, how can it at the
same time not be a participating resource?

These are all excellent questions to ponder while sitting in traffic, while
waiting for the previews to begin in a theater, or, indeed, while in the
lotus position.

                             - John Simpson, Just XML, p.111
---------------------------------------------------

I bring this example up not because the question is intractably difficult -
we've been over it, to some extent, in the xlxp-dev list - but because of
the capacity it has for mystifying people, even quite advanced XML users.
Extended links and document groups have similar koans built into them at
present.  What's in the middle of an extended link?  Nothing - and
something, simultaneously.  

While this may not feel like a problem to those who have spent many years
working with hypertext, it gives XLink a dose of mysticism that competes
even with RDF.  Sitting in the lotus position should not be a requirement
for understanding a set of hypertext tools.

Making the shift from a link as a traversable path to a link as a set of
resources with roles and behaviors is going to take Web developers (and
others) considerable effort.  The previous Working Draft pretty much
ignored these concerns, locking these developers in a simple link sandbox
that had very little connection - apart from the names of certain
attributes - to the rest of the standard.  Lost in that sandbox approach is
one of the most powerful bonuses of using XLink, the ability to specify
clearly understood traversable paths out-of-line, or, better, in external
documents for simple management.

Producing a link standard that gets use - lots of use - means dealing with
some difficult problems head-on, and relating new concepts to widespread
practice.  Most authors and writers of hypertext today are working on the
Web, where the reduction of link to traversable path was the
'worse-is-better' approach that finally got lots of people using hypertext.

Links have to relate to the tasks authors and readers perform every day, or
we're all going to be stuck with yet another hypertext standard that
receives little implementation and less use.  Writing a standard that
reaches out to the largest body of developers and authors possible - by
addressing their expectations and needs - is the only way to ensure XLink
is more than a W3C recommendation, becoming a core part of the Web
development toolkit rather than a quietly ignored specification.

Simon St.Laurent
XML: A Primer
Sharing Bandwidth / Cookies
http://www.simonstl.com

Received on Tuesday, 23 March 1999 10:07:37 UTC