[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: TAG on HLink
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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|