[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]
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. To my mind, by the way, the inclusion of default and fixed attributes on an element *is* a transformation that is specified in a schema. It happens to be a very common transformation, one that is supported in DTDs and in W3C XML Schema, but it is no less a transformation. I guess that my argument would be that if you are happy for this restricted kind of transformation to be specified within a schema, then why not allow for the specification of more flexible transformations as well, including those that can deal with the facts that (a) people, it seems, want to use domain-specific terminology when naming attributes that hold URIs (which could be handled by an AF) and (b) people want to be able to specify multiple links from the same target without using separate elements for each of them (which needs something more sophisticated). I'm not sure that I would really choose to specify the linking semantics of an element in terms of a transformation to XLink (I think I'd probably prefer the second of the suggestions that I made -- a way of annotating attributes or elements to indicate that they are links) but it's preferable, to me, compared to forcing users to link to or specify explicitly the same HLink spec from each of their HTML documents. > The only objection I've seen so far to XLink that is not based on > fundamental misunderstandings of XLink is the desire to put multiple > link attributes on a single element instead of using extended links. > I'm sympathetic to this position. But even here, there might be a > middle ground. An element such as object can contain multiple simple > link elements rather than all the extended link locator, arc, label > fru-fru. For example, > > <object width="100" height="100" other_non_linking_attributes="..."> > <source xlink:href="http://www.example.com/MyImage.jpg"/> > <longdesc xlink:href="http://www.example.com/description.html"/> > <map xlink:href="http://www.example.com/map.txt"/> > <alt> > In this scheme we can put a <strong>lot</strong> of markup here. > </alt> > </object> > > I think this is pretty straight-forward, pretty easy to type, and in > many ways much cleaner than the current approach. Although I'd argue that it doesn't correctly reflect the semantics of the elements. As simple links, the source, longdesc and map elements are the resources which are linking to the URLs specified in their xlink:href attributes. I would have thought that the extended link semantic, which makes the alt text the local resource, is more accurate (though it still doesn't feel quite right, but I don't know how to make the object the local resource using XLink?). I take your point that this is a compromise, but I've observed that the designers of markup languages tend, stubbornly and arguably wrong-headedly, not to like compromising in their design simply to comply with the semantics of another markup language (especially when, unfortunately, that markup language does not have many strong arguments for it in terms of application support). My feeling is that it is better to develop methods that enable markup language designers to design the language that *they* want, that suits *their* domain, and to have that structure mapped on to or otherwise recognised as having the common semantic, in this case of being a link. Cheers, Jeni --- Jeni Tennison http://www.jenitennison.com/
|
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
|