Re: xlink:href

On Tuesday, July 2, 2002, 3:18:04 PM, Paul wrote:


PP> TBL says:

>> You should use xlink
>>     whenever your application is one of hypertext linking,
>>     as xlink functionality such as power to control user
>>     interface behavior on link traversal is useful and
>>     should be implemented in a standard way to allow
>>     interoperability.

PP> I do not encourage people to use XLink for a few reasons. 

PP> First, I feel that it is too syntactically intrusive. The same goes for
PP> RDF and SOAP. People authoring XML should not need to keep six different
PP> namespaces in their head.

That cuts both ways. Lets take another namespaced thing as an example
for discussion, so that you other points about xlink do not apply.

xml:lang identifies the language of the content of the element. But it
involves using that "syntactically intrusive" xml: so lets define our
own attribute called lang or la or language or langue or Sprache.

So then, in traversing a collection of documents, or a multi-namespace
document and looking for language information (perhaps a translation
memory tool is looking for translatable text) it has to understand all
the namespaces in use and their particular way of identifying lanuage.
Which is more burdensome than just looking for xml:lang.

Going back to XLink htef, its much easier to look for href (and show
and actuate and role and arcrole depending on what information you are
looking for) in the namespace identified by the XLink URI, than it is
to figure out the one-of linking syntax invented by every namespace on
the planet.

PP> Also, I do not think that a particularly rich or interesting layer of
PP> software has evolved to support XLinks that can do meaningful things
PP> with them without understanding the rest of the application. Under what
PP> circumstances would I care that when a link is clicked it brings up a
PP> new window but not care whether the surrounding <para> elements are
PP> represented as paragraphs? XML on the Web is almost always transformed
PP> from a local vocabulary to a display vocabulary (whether that
PP> transformation happens on the client or server).


Ah, the 'make it into HTML for display and HTML has links already"
argument. Thats fine if high variability of implementation, low
functionality, and minimal correspondence between specified behavior
and actuial practice are acceptable.

For cases where it is not, XLink is one component of a better
solution. In particular, XLink simple links are one easy entry into,
or simplification of, XLink complex links.

PP>  Why must hypertext
PP> links get special handling?

Because without them, the content sucks.

PP> XLink might be a little bit more interesting if it was used everywhere

Sure, if XHTML had used it and if SMIL 2 had used it instead of
copying XHTML, then that would start to be an interesting corpus of
technologies that all did linking the same way. No disagreement there.

PP> one XML element referenced another (e.g. <xsd:include>, <xsl:import>,

That would have been good, too - instead of a (bunch of) PIs, use an
XLink complex link to point to main and alternate stylesheets, define
media, etc.


PP> ....). Then it could be used as the basis for link checking and
PP> validation.

Yes.


-- 
 Chris                            mailto:chris@w3.org

Received on Thursday, 4 July 2002 04:54:36 UTC