[
Lists Home |
Date Index |
Thread Index
]
Hi Ben,
Ben said:
Would it not be better, therefore, to drop the current XLink completely
and simply call HLink `XLink 2.0', since it doesn't really seem to
have too much to do with XHTML.
Didier replies:
I think that we should push groups to think more about the issue. As far
as I am concerned, even Hlink is based on a too narrow mindset. For
instance, how would you process an XHTML document that includes HLink
with XSLT. I mean here, a generic stylesheet understanding a link in
diverse domain languages. As you know, actually, only SGML can do that
with architectural forms, and the only styling language than can process
such things is DSSSL. If you declare that the element <img src=".URI."
longdesc=".URI." > derives its architectural form characteristics from a
link, <link href=".uri."> then DSSSL will be able to process a rule like
(element link .....) (1) to match a rule with an element deriving from a
link) even if, in the document, includes, in fact, <img...>. elements.
It leads to clean, easy to read and re-usable stylesheets. So, the
question is: Can XSLT do such things with HLink and thus help us re-use
generic stylesheet code? So, it's the XML framework that is involved
here not only the product of a single Work Group (i.e. XHTML).
Moreover, if you look closely to a web page you'll notice that it is
composed essentially of text and images. Code embedding (applet,
activeX, plug-ins) is rarer. This may lead us to conclude, with a
reasonable probability, that SVG+ XHTML can, in the future, be a common
combination. But a link in SVG is expressed as an xlink derived element
and this is not the case for XHTML. In the same document produced by two
W3C byproducts we have two ways to express the same concept: a link. I
am not talking about image embedding here, I am talking about the <a>
element. Off course, W3C work groups will be very efficient and creative
to justify such result like any schizophrenic patient is to justify
his/her own state.
My point is: Let's keeps the therapy going, the patient suffers with an
acute access of schizophrenia :-). Said more seriously, the XML
framework is logically inconsistent at least when we considers these
simples constituents:
a) XHTML
b) SVG
c) XSLT
It's a proof that:
a) maybe the W3 consortium reached its point of incompetence being not
able to pull all its constituents toward a coherent frame.
b) maybe we reached a point where the basic rules of XML prevent it to
be as versatile as SGML. Said differently, we have reached its inherent
limits.
c) we didn't used enough brain food to come with intelligent solutions.
d) We miss somebody who will work that out as a unified framework (seems
to be better with a single mind or a few minds).
I have not lost my trust in W3C and I am a patient man. Obviously, there
is a need for a third party to help the kids play the same game, in the
same playground. If the XML framework is becoming too schizophrenic,
then another technology not suffering from the same disease will take
over.
Cheers
Didier PH Martin
|
