Re: two failings of XLink

Hi Elliotte,

>>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?
>
> A "generic XLink processor" isn't going to display anything. It does
> not have sufficient information, and probably isn't designed to
> display things. A generic browser might load a stylesheet and apply
> it to the document to figure out how to display it. An XSLT
> stylesheet could figure out which parts to expose and which not to.
> A CSS stylesheet could at least hide certain parts of the
> information. A browser without a stylesheet to depend on probably
> should just display everything including the markup, as IE does now,
> and let the user sort it out. And in that case, it's probably best
> to let the user select whichever link they want, and show them all
> rather than trying to pick between them.

Maybe it depends on what you mean by a generic XLink processor. I mean
an application that uses only knowledge about XLink in order to do
something with a document. For example such an application might
display a pretty picture of the links contained in a document, using
information from the xlink:title and xlink:role/arcrole attributes to
display the content in different ways; see [1] for some examples of
what an XLink processor could do (though these are obviously not
created from XLink pages).

Or it might be a generic browser (e.g. giving a tree view of the
document, like IEs of XML documents, but linking from linkable
elements) or a generic editor (similarly), of course. I don't think
that there's any reason to assume that an XLink processor shouldn't be
able to do anything presentation-wise with a link without a
stylesheet.

But anyway, my point was that because stylesheets don't give you a way
to react to dynamic events in the document, I don't think that they
can know that they should display a graphic in place, unless the
graphic is not found, in which case they should display the content of
the <src> element's parent <object> element (aside from the linking
elements of course -- they should be ignored). If you can do that with
CSS, I'd honestly love to see it!

>>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.
>
> Perhaps that might be addressed by a robots processing instruction,
> but I'm not sure. I haven't looked at XForms that closely.

It's worth a look, both because it's pretty cool and because it's very
relevant to this discussion. XForms used to use XLink but has dropped
it for various reasons that I'm sure Micah will happily go into.

Cheers,

Jeni

[1] http://www.cybergeography.org/atlas/surf.html

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

Received on Friday, 27 September 2002 14:57:46 UTC