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

[Jeni Tennison <jeni@jenitennison.com>]

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/