Re: Links are links

>> So why do we insist on this distinction between hypertext links and
>> other links? Software doesn't care. I think that the software will
>> work better if don't force arbitrary distinctions on it. And in
>> fact, XLink has MUCH better traction in software engineering shops
>> than in hypertext shops *today*. So the market has defacto rejected
>> the distinction.
>
> this would imply that, if XHTML "should" use XLink, then it "should"
> be used for all the references to resources, which implies that the
> TAG's directive/suggestion has a lot bigger impact than they seem to
> be imagining.

The TAG doesn't imagine anything as one group-mind.  What we agreed on
was a simple statement that if a new XML language is being created and
that language defines hypertext references for user-interface oriented
applications, then that language should use XLink.  That is, after all,
why it was published as a Recommendation.

My personal opinion is that a hypertext reference is any link that
partakes in the engine of application state.  Those are sometimes
referred to as active or operational links.  My guess is that the
other TAG members were thinking only of those references that initiate
state changes, which includes anchor href and form submit.
Either way, HLink is not a viable solution because it is specific
to XHTML (by definition, even if not by technology).

Regardless, my opinion is that the XHTML WG cannot on the one hand say
that they are abandoning backwards compatibility and on the other hand
claim that backwards compatibility prevents them from adopting XLink.
If XLink in its current form is unsuitable for XHTML 2.0, then I believe
it is unsuitable for any language and should not be a Recommendation.
It is therefore necessary for those people ill-effected by XLink's
status to either come up with XLink 2.0 (not another format-specific
meta-markup language) or use the W3C process to change the status
of XLink to better reflect its real status within the W3C.

As a technologist, I find that XHTML's predilection towards defining
vague element types, with arbitrary variance in functionality based
upon what attributes are found within the start tag of those elements,
to be poor XML language design.  It doesn't surprise me at all that XLink
does not support several orthogonal actions within the attributes of
a single tag -- an action shouldn't be defined by the tag's attributes
in the first place.  XHTML 2.0, if it is to exist at all, is the place
where the cruft of a decade of HTML add-ons should no longer impact
the design of XHTML mark-up, and thus XHTML's "requirements" on XLink
must be motivated by what is necessary to support optimal mark-up,
not what is necessary to support tag soup or attribute trees.

Finally, as an elected TAG member, I feel that I must remind everyone
who feels slighted by a TAG finding, note, or recommendation of the
following fact: The AC members did not elect me to parrot their own
opinions or to make decisions that are subject to the AC member voting
process.  If such were desired, the AC would simply vote themselves
and save us the effort.  I was elected so that we could inform WGs
that they are about to step off a cliff before they actually make
that step, rather than after they have hit the rocks below.

Cheers,

Roy T. Fielding, Chief Scientist, Day Software
                  (roy.fielding@day.com) <http://www.day.com/>

                  Co-founder, The Apache Software Foundation
                  (fielding@apache.org)  <http://www.apache.org/>

Received on Monday, 30 September 2002 18:51:21 UTC