RE: two failings of XLink

Hi Simon,

Simon said:
I'm afraid it's not very different.  Extended links require multiple
elements to express <img src="bogus.jpg" longdesc="bogus.txt" />.  They
may be child elements, but there's more than just a few extra tags
involved.

Didier replies:
In the absolute I would say that it is a good argument against xlink if
we absolutely want to pack all the links inside a single tag and that we
want absolutely package these links as attributes. If that is the rule,
it should be applied to the other languages produced by W3C WG. So,
Let's now apply a common sense filter to this axiomatic statement.
What's in it for me? Is this giving me something better? Is my life or
the life of my customers/readers/users is improved? Or for internal
coherence and logical consistence in the XML framework, that all domain
languages produced by W3C to be constrained by this rule. At least this
would reduce the "surprise effect" each time a new spec is out :-)

Before going on, I have to mention that I wasn't able to find the image
module mentioned in the client side image map module. It seems that an
<img> element is included in it. Is it the same one we know from the
previous specs? Maybe, but it would be conjectural thinking from my part
since I wasn't able to explicitly find what it is from the XHTML 2.0
specs (no image module included in the XHTML 2.0 specs). 

If, as mentioned in your example, we use an <img> element containing two
links, then it would be useful to have them packaged as xlink extended¸.
Why? Answer: XSLT stylesheet re-use. I may create an XSLT style sheet
that transform any xlink extended elements (or more precisely, any
element inheriting the xlink extended characteristics) into a context
menu. My final XSLT style sheet can *re-use* my xlink extended
stylesheet and thus:
a) reduce my development costs
b) provide me the opportunity to overload the default behavior provided
by the browser. So to speak, since my XHTML document is also an XML
document, to include a stylesheet processing instruction that will
change the rendition rules for the XHTML document. My style sheet may
provide a more usable visual gizmo in a particular context. The browser,
will only provide a default behavior that may not be the best one for
the intended audience or usage.

I gained something here:
a) new possibilities
b) reduced development costs through *re-usage*
c) the possibility to develop XSLT stylesheet libraries that could be
applied in different contexts this may induce some networking effects
for XSLT since it would promote the construction of stylesheet
libraries.
d) reduced the mental workload to recognize what is a link and what is
not a link.
e) give what XML implicitly promised us: versatility.

So, if we now use a rule of practicality, or a rule of re-usage, we may
end up with a different conclusion. A conclusion having far more
impacts:
a) on the bottom line
b) on what I can do
c) on the possibilities that are opened to me

In the absolute, any axiom is valid since an axiom is:
"A self-evident principle or one that is accepted as true without proof
as the basis for argument; a postulate".
The question now is: is this axiom useful? What in it for us? What are
the gains?

So I stated the gain I get by having an <img> element when it inherit
the xlink extended attributes. I am listening the what are the gain I
get from having multiple links in the same tag. There should be some and
I would be glad to read them. 

As a final note, in contrast to science, engineering reasoning is
constrained by utility or costs. Thus an engineering thesis is better
then an other one if it is more useful or less costly. A science thesis
is constrained to other criteria. I just said that in order that we do
not forget the contexts for all this.

Cheers
Didier PH Martin

Received on Thursday, 26 September 2002 16:48:08 UTC