Re: Generic link handling

Chris Lilley wrote:

> Part of the issue is that some folks do not reliably distinuish
> between an attribute of type anyURI, which there can be lots of per
> element, and a link (which can have only one such attribute that forms
> the link URI, if there is to be any metadata also associated with
> that link  using standard and readily recognisable attribute names).

In my opinion, a link is an assertion of a relationship between two 
resources. No more. No less. It has nothing to do with elements or 
attributes or anyURI etc. If it did, then PDF documents could not have 
links, which they clearly can.

I think that Ann is right that if the attributes of type anyURI assert a 
relationship that a spider might want to investigate through traversal 
then they _are links_. That was why I raised the question. We've got all 
of these links floating around that are not recognized as links even 
though any reasonable spider or link checker would treat them such. This 
is going to destroy the utility of spiders and link checkers.

According to my definition, it is common in (e.g.) RDF to have a link on 
an element with _no_ attributes:

<someNs:someClass>

is, in the appropriate RDF context speak, an assertion that the 
described object is of type someClass.

Given that, it is probably not likely that there will ever be one and 
only one XML linking syntax. RDF and XHTML are probably never going to 
agree on a linking syntax. But I could imagine a universe in which there 
are two, or three, or four linking synaxes and not one per W3C 
specification. 4 is a big improvement over N, especially as N is always 
growing.

Once we separate out the CONCEPT of linking from the SYNTAX of linking, 
your argument with Ann ceases to be definitional: "Those are links. No 
they aren't. Yes they are" and can instead be pragmatic: "The way you 
want us to make links is ugly and verbose." "The way you want to make 
links is not extensible enough."

  Paul Prescod

Received on Tuesday, 3 December 2002 13:21:03 UTC