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

Re: [Fwd: The problems with Xlink for integration langu ages]

• To: Jeni Tennison <jeni@j...>
• Subject: Re: [Fwd: The problems with Xlink for integration langu ages]
• From: Uche Ogbuji <uche.ogbuji@f...>
• Date: Thu, 19 Sep 2002 08:22:23 -0600
• Cc: Elliotte Rusty Harold <elharo@m...>, xml-dev@l...
• In-reply-to: Message from Jeni Tennison <jeni@j...> of "Tue, 17 Sep 2002 15:09:16 BST." <88924531075.20020917150916@j...>
• Sender: uche.ogbuji@f...

> Hi Elliotte,
> 
> > Absolutely. However, please don't fall into the trap of assuming
> > that XLink has to be as complex as some of the examples in this
> > thread. Perhaps out of ignorance, perhaps deliberately, these are
> > much nastier than they would have to be in practice. For instance, a
> > basic img (Excuse me, object) element might look like this:
> >
> > <object xlink:href="http://www.example.com/image.jpg"
> >          width="100" height="100" other_non_linking_attributes="..."/>
> >
> > That's all. xlink:type and the namespace declaration would be
> > defaulted in from the DTD. The DTD would be built into web browsers
> > which would recognize the public identifier for XHTML 2.0. The other
> > link attributes would be either defaulted or ignored. XLink does
> > allow applications to define their own semantics and behavior for
> > links, and to ignore or change the behavior suggested by attributes
> > like xlink:show.
> 
> Absolutely -- the anticipated use of XLink is one in which you specify
> the semantics that are common across all instance documents *within
> the schema*, which is what I'm arguing for, rather than *within the
> instance document*, which is what HLink does.


Behavioral aspects of linking should certainly have a mechanism for override 
in the instance.  I believe this is the job for CSS.  I am also not convinced 
that there should be no mechanism for expressing linking semantics in the 
instance document.  In particular, I do not think extended links should be 
ditched, and I think that extended links would require some semantic notation 
in the instance.

People always say they don't "get" extended links and then go right on to 
reinvent them.  Right now, HTML authors build extended links using rickety 
prefabs of simple links and Javascripting.  Even the HTML WG has sorta 
reinvented them in the new navigation links thingie (and possibly in other 
places).  I think that almost any declarative approach to extended links would 
be easier for Web designers than figuring out what combination of iffy HTML 
and specialized scripting can be made to somewhat work in the variety of 
browsers.

So I'm not buying any of this argument that linking description should be 
restricted to the schema.  I don't think all the machinery of extended links 
need be exposed in the instance.  Just enough (perhaps the arcroles) to allow 
CSS an anchor for describing the behavior.


-- 
Uche Ogbuji                                    Fourthought, Inc.
http://uche.ogbuji.net    http://4Suite.org    http://fourthought.com
Apache 2.0 API - http://www-106.ibm.com/developerworks/linux/library/l-apache/
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

• Follow-Ups:
  • Re: [Fwd: The problems with Xlink for integration langu ages]
    • From: Jeni Tennison <jeni@j...>

• References:
  • Re: [Fwd: The problems with Xlink for integration langu ages]
    • From: Jeni Tennison <jeni@j...>

• Prev by Date: RE: Is there a difference that makes a difference between topic maps and named queries?
• Next by Date: Re: Push / pull model
• Previous by thread: Re: [Fwd: The problems with Xlink for integration languages]
• Next by thread: Re: [Fwd: The problems with Xlink for integration langu ages]
• Index(es):
  • Date
  • Thread