[
Lists Home |
Date Index |
Thread Index
]
At 12:14 PM 9/26/2002 -0400, Simon St.Laurent wrote:
>The first is the shift from XLink's early conception as a set of
>structures that could be mapped into any vocabulary to XLink as a set
>of attributes in a particular namespace that can be added on top of any
>vocabulary. That means that every hyperlink must be xlink:href,
>whatever it's purpose. There's no room for <img src="" /> in XLink.
I tend to agree with Simon on this one. HLink's attribute
remapping is really quite nice, for people who are into that sort of thing
(which I'm not, personally, but I recognize the value of it). Perhaps the
XLink WG could take it up, a sort of XLink 1.1?
In fact, XHTML 2.0 could then describe a set of linking semantics
that are assumed within their namespace by processors. "HLinks" could be
defined as being a necessary part of XHTML, pre-defined for common tags
that people are used to (like A, IMG, etc.). Sure, it's not pure XML to do
so, but it makes sense. How many browsers bother with DTDs, anyhow?
It seems to me that the answer is not to make HLink it's own
special citizen, but rather to subsume its functionality into XLink, so
that we have both unity and effectiveness.
>The second issue is the only-one-URI-per-element rule. While I can
>understand to some extent the arguments in favor of that from an
>abstract point of view, in practice it seems bizarrely limited if not
>simply broken.
Agreed. The question is, how to define that the other attributes
are URLs in an unambiguous fashion? I note that HLink doesn't seem to have
solved that problem.
>XLink may be suitable for situations where the designers have a
>conception of linking that corresponds to XLink's existing structure and
>where mixing namespaces at the attribute level is accepted as a matter
>of course.
I think that "mixing namespaces" is no big deal. My guess is that
HTML people will have as much confusion, if not more, over the other
differences in XHTML 2.0 as they would to a namespace on an attribute.
>Unfortunately, that does not appear to be the case with (X)HTML, which
>has a long history, a slightly different conception of hyperlink
>structures, and a user base of millions. The W3C appears to have
>forgotten its origins completely in this case.
I doubt it. It's more likely that childish political infighting at
the W3C is more the cause. The responsibility of a standards organization
is to set standards -- in part so we don't all have to rewrite our code for
applications that have very similar uses. I find the whole debate over the
linking problem silly, which led me to drop out of the conversation last
month. Too few people seemed focused on solving the problem, and more
seemed interested in complaining and not budging.
Steven Pemberton's response to TAG
(http://lists.w3.org/Archives/Public/www-tag/2002Sep/0188.html) seems to be
more of the same. "It is not clear you have the authority to say that"
smacks of "Waaah! We're not going to play!"
Frankly, the steps forward seem obvious to me: get the XLink WG to
yank in the appropriate functionality that HLink provides (minus multiple
URIs on one element, an XHTML requirement that HLink does not appear to
address), and then have the two groups sit down and solve the rest. That
way, HLink's attribute remapping benefits can be provided to everybody, and
XLink can remain the central point for XML-based hyperlinking.
Seems pretty straightforward to me, if all the kids would agree to
play in one sandbox.
--->Ben
|
