Re: two failings of XLink

At 4:13 PM +0100 9/27/02, Jeni Tennison wrote:

>Is it that you think that multiple simple links can be used instead of
>an extended link in all cases (in other words that extended links are
>superfluous in XLink)?
>If not, could you give an example where you think that extended links
>*would* be a good fit for a markup language's requirements, and
>describe how your example is different from the example with the
><object> element in XHTML?

I think out of line links and linkbases really require extended 
links. I don't think you could handle that with multiple simple 
links.So for example I could have many different slide documents, and 
use different linkbases to pick and choose different combinations of 
those to assemble into one slide show. However, the HTML links are 
very much inline.

>pretty useless. But if I write an XLink harvester then I count that as
>a *generic* XML tool and expect that it should treat all XML documents
>(including XHTML) alike, that it should use the XLink semantics as
>defined in the Rec. and should bail if it encounters something other
>than XML.

What I'm proposing is still legal XLink. The object on harvester 
grounds is that the harvesters won't recognize this is as one link 
instead of several. You know, I'm not sure this isn't several links. 
The case in point certainly identifies several resources. We're not 
just talking about mirror copies here. We're talking about text vs. 
images, pictures at different resolutions. Arguably we do have 
multiple links and a generic XLink processor will want to follow all 
of them. That's not what an XHTML processor is going to want to do. 
It will pick and choose base don its knowledge of XHTML.

| Elliotte Rusty Harold | | Writer/Programmer |
|          XML in a  Nutshell, 2nd Edition (O'Reilly, 2002)          |
|                  |
|  |
|  Read Cafe au Lait for Java News:      |
|  Read Cafe con Leche for XML News:    |

Received on Friday, 27 September 2002 11:47:45 UTC