[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: TAG on HLink
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
|
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
|