Re: generic uselessness (was Re: two failings of XLink)

Hi Simon,

> Jeni Tennison writes:
>> For what it's worth, I think that 'arcs' are the most problematic
>> (and objectionable) aspect of adopting the extended link syntax.
>> (Which isn't to say that I don't think there are other issues about
>> using XLink, just to try to highlight this one.) Perhaps XLink
>> could just drop them and we could use some other method (e.g. XML
>> Events) to describe how and when resources were loaded.
>
> That's very funny to me, since I consider extended links utterly
> useless in multi-ended hypertext linking when arcs aren't present.
> Sets are nice for some applications, but if I'm presenting text to a
> user, it's nice to know which resources are actually connected, and
> XML Events are a hideous approach to doing that.

Two points here.

First, I agree that it's useful to know which arcs are navigable
between resources, and how and when those arcs can be traversed. It's
just that the amount of syntax that's needed to indicate the arcs is
huge, and it's especially burdensome because they need to be
represented by *elements* and unlike attributes, you can't default
element content. Micah's suggestion of xlink:type="local-extended"
would go some way to helping that, but we're still stuck with things
like:

  <link>
    <from xlink:href="from.xml" />
    <to xlink:href="to.xml" />
    <go />
  </link>

where xlink:type="local-extended" wouldn't help. What's annoying in
these cases is that the empty <go> element is something that's common
to every single <link> element, expressing exactly the same arc in
every single one. Information that's common to every document is much
better placed in a schema or other description of a markup language --
you shouldn't have to repeat it in every single instance. If XML
Events suffered from the same problem, then they wouldn't be much of a
solution either; I only mention them because they seem to be about
deciding what to do about particular events, and it seems that
traversal of links falls into that category.
  
Second, I do think that part of the problem here is the mixing of
requirements between people who want to represent the relationships
between different resources (see them as a set of resources) and those
who want to represent the traversal between them (see them as ends of
a link). XLink ended up doing both and, as I think is usual in cases
where a technology tries to do two things at once, ends up being not
particularly well suited for people who only want to do one and not
the other.

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/

Received on Friday, 27 September 2002 18:49:04 UTC