[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]

Re:  [Fwd: The problems with Xlink for integration langu ages]
> 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 

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 - 
Keeping pace with James Clark - http://www-106.ibm.com/developerworks/xml/libra


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.