[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Re: Can XLink be fixed?

• To: Bob DuCharme <bobdc@s...>, xml-dev@l...
• Subject: Re: Re: Can XLink be fixed?
• From: Elliotte Rusty Harold <elharo@m...>
• Date: Fri, 16 Aug 2002 11:46:18 -0400
• In-reply-to: <5.0.0.25.0.20020816102135.009d3c50@m...>
• References: <<r01050300-1015-51AA1A58B09811D683CE0003937A08C2@[192.168.124.21]><r01050300-1015-51AA1A58B09811D683CE0003937A08C2@[192.168.124.21]><5.0.0.25.0.20020816102135.009d3c50@m...>

At 10:23 AM -0400 8/16/02, Bob DuCharme wrote:


>The XLink Rec claims to only define the existence of a link between 
>resources (two resources? Elliotte, you of all people!) , but then 
>it defines, or at least makes some very clear suggestions, for quite 
>a bit of link behavior with the xlink:show and xlink:actuate 
>attributes.

Yes, but it's also clear that:

1. An application does not need to use or support xlink:actuate or 
xlink:show if they don't make sense for that application domain, 
either by implicitly ignoring it or setting the value to other or 
none.

2. Even when xlink:actuate and xlink:show are set to specific values 
individual programs can ignore those suggestions. For instance, a web 
spider might well ignore any link with xlink:show="embed" and 
automatically actuate all other links.

>  I think that addressing link behavior to the extent that it does is 
>one of the biggest problems with XLink, and the fact that what 
>little scattershot implementation of XLink that is out there either 
>implements the behavior part *or* the typing, arcrole, etc. parts 
>shows that these fall into different architectural levels that 
>really should be treated separately.
>

I think xlink:show and xlink:actuate were mostly intended to 
reproduce the existing semantics of different kinds of HTML links. 
For the most part, I think simple XLinks map to HTML fairly well. I'm 
a little surprised the HTML folks object to these so strongly. The 
major argument I see against XLink is the question of backwards 
compatibility and familiarity, but XHTML 2.0 has already tossed these 
worthy goals in the trash bin, so I don't think they can object to 
XLink on these grounds.
-- 

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@m... | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|          XML in a  Nutshell, 2nd Edition (O'Reilly, 2002)          |
|              http://www.cafeconleche.org/books/xian2/              |
|  http://www.amazon.com/exec/obidos/ISBN%3D0596002920/cafeaulaitA/  |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      |
|  Read Cafe con Leche for XML News: http://www.cafeconleche.org/    |
+----------------------------------+---------------------------------+

• Follow-Ups:
  • RE: Re: Can XLink be fixed?
    • From: "Didier PH Martin" <martind@n...>

• References:
  • Re: Re: Can XLink be fixed?
    • From: "Simon St.Laurent" <simonstl@s...>
  • Re: Re: Can XLink be fixed?
    • From: Bob DuCharme <bobdc@s...>

• Prev by Date: Re: Re: Can XLink be fixed?
• Next by Date: WXS acronym?
• Previous by thread: Re: Re: Can XLink be fixed?
• Next by thread: RE: Re: Can XLink be fixed?
• Index(es):
  • Date
  • Thread