Re: two failings of XLink

Hi Elliotte,

> I think out of line links and linkbases really require extended
> links. I don't think you could handle that with multiple simple
> links.So for example I could have many different slide documents,
> and use different linkbases to pick and choose different
> combinations of those to assemble into one slide show. However, the
> HTML links are very much inline.

OK, I can see that out-of-line links have to be extended. Are those
the only kinds of links that can be extended, in your view? I guess
that in that case, the point of 'resource' type elements is to supply
additional information for the link, and the extended links themselves
should all be in a special document (i.e. all extended links would be
in linkbases). Is that how you see it?

I think that part of the reason for our disagreement is a conceptual
one, that you see the various links associated with an object as
stand-alone, or at least having no link-related or XLink-specified
relationship with each other, whereas I view the various resources as
being connected by virtue of representing information about the same
object, and I think that this relationship is expressible in XLink and
so XLink should be used to express it.

Perhaps out-of-line links would be a solution here. We could have:

  <object id="img1">
    Look Mom! We can put alternate text here!
    We can even <strong>markup</strong> the alternate text.
  </object>

inline and then, perhaps in the <head> of an XHTML document do:

  <link>
    <longdesc xlink:href="http://www.example.com" />
    <src xlink:href="http://www.example.org" />
    <alt xlink:href="#img1" />
    <srcOnLoad />
    <longdescOnRightClick />
    <altOnFailure />
  </link>

where <srcOnLoad> etc. are 'arc' type elements to describe when and
from where each of the links should be navigated.
  
>>pretty useless. But if I write an XLink harvester then I count that
>>as a *generic* XML tool and expect that it should treat all XML
>>documents (including XHTML) alike, that it should use the XLink
>>semantics as defined in the Rec. and should bail if it encounters
>>something other than XML.
>
> What I'm proposing is still legal XLink. The object on harvester
> grounds is that the harvesters won't recognize this is as one link
> instead of several. You know, I'm not sure this isn't several links.
> The case in point certainly identifies several resources. We're not
> just talking about mirror copies here. We're talking about text vs.
> images, pictures at different resolutions. Arguably we do have
> multiple links and a generic XLink processor will want to follow all
> of them.

It depends what kind of XLink processor we're talking about, but if I
was using a generic XLink browser with DocBook (to pick a random
example to get away from the argument that XHTML is going to be
treated specially) then I'd expect it to honour the xlink:show and
xlink:actuate attributes. The advantage of using an extended link is
that you can expect it to correctly embed only one of the chosen
resources. For example, in your <object>:

  <object xmlns:xlink="http://www.w3.org/TR/1999/xlink">
    <longdesc xlink:href="http://www.example.com"/>
    <src xlink:href="http://www.example.org"/>
    <someotherlink xlink:href="http://www.example.net"/>
    Look Mom! We can put alternate text here!
    We can even <strong>markup</strong> the alternate text.
  </object>

I don't know how a generic XLink processor would know that the
alternative text should *not* be displayed if the (simple) <src> link
has been embedded. Given that you're suggesting this tactic (of using
simple links rather than extended ones), have you got any ideas about
how a generic XLink processor would deal with a similar situations
without having specialist XHTML knowledge?

I believe that there are also some issues here on the XForms side that
say that just because an XLink processor (talking harvester here)
encounters an xlink:href doesn't necessarily mean it should navigate
to the specified URL with a GET request, but I guess that's a
different argument.

Cheers,

Jeni

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

Received on Friday, 27 September 2002 13:56:04 UTC