[
Lists Home |
Date Index |
Thread Index
]
> I've been thinking through XLink again and in particular some of the
> comments on this list. XLink's supporters seem to think that XLink is
> virtuous because it does more than HTML but less than HyTime, if I may
> grossly over-generalize.
>
> While I appreciate the need to do more than HTML 1.0, I also think it's
> pretty obvious that a much wider segment of the world is happy with
> href, src, and longdesc than is interested in either complex links or
> RDF.
Really? I hadn't even *heard* of longdesc until this discussion. As for href
and src, I imagine people use it because that's what they have. I imagine
Webmasters everywhere would like not to have to remember one attr for a and
another for img. And I'm sure they'd be just as happy if that attribute had
been called "link" instead of "href".
> Those of us who are interested in complex links (myself included)
> may find this genuinely depressing, but I think it's a fair statement of
> the overall situation.
Enough people re-invent complex links *all the time* in Web authoring that I
disagree that it is not a wide need or interest. It just so happens that HTML
1.0 has nothing for it, so people must reinvent. I see no reason to believe
that people would not have used complex links if they had been in HTML.
> Given that, I have to say that I find the XHTML 2.0 specification's
> decisions to support href on everything (as in <li
> href="#fish">fish</li>) and to use the familiar object element for
> including foreign resources to be painfully sensible, however much they
> may impinge on the sensibilities of XML and especially XLink people at
> times.
What am I missing here? What about the loud cries of "we need more than one
link on an element"?
"href" on any element is a straight-up loser. This has nothing to do with
"sensibility". I think Norm had it in his brilliant summary just for
completeness, but I never once considered it a serious option.
> Allowing href on everything - whether or not it has the unnecessary
> xlink: namespace slapped on it - is a much larger advance in making
> hypertext broadly useful than any attempt to rewrite XHTML to take
> advantage of complex links.
> If there's an 80% of the value with 20% of the effort here, I think the
> XHTML Working Group may well have found it.
I disagree. IMO, what I can see so far of XHTML 2.0 just perpetuates bad
markup practice, as Tim Bray said. Since XHTML is chartered to ignore
convention in favor of The Right Thing, I'm not sure why clinging to "href" is
such a necessity.
BTW, I know Ann will protest this characterization, but I've read *every* link
that has been pointed out in this thread and all I see after various red
herrings are marked off is a desire to cling to "href" while adding a handful
of other similarly limited attributes on the same element as that on which the
href appears. If there is any more nuance that I'm missing, then I can change
my mind when sundry mysterious documents finally appear. Until then, I'm
going on what I can see and read. Period.
--
Uche Ogbuji Fourthought, Inc.
http://uche.ogbuji.net http://4Suite.org http://fourthought.com
Track chair, XML/Web Services One Boston: http://www.xmlconference.com/
Basic XML and RDF techniques for knowledge management, Part 7 -
http://www-106.ibm.com/developerworks/xml/library/x-think12.html
Keeping pace with James Clark - http://www-106.ibm.com/developerworks/xml/libra
ry/x-jclark.html
Python and XML development using 4Suite, Part 3: 4RDF -
http://www-105.ibm.com/developerworks/education.nsf/xml-onlinecourse-bytitle/8A
1EA5A2CF4621C386256BBB006F4CEC
|
