Subject: Re: Fw: XSL-T, XTL.... or XQL? From: Guy_Murphy@xxxxxxxxxx Date: Fri, 5 Mar 1999 15:49:07 +0000 |
Hi. Actually I didn't expect anybody to bite the bait but hey, it was worth a try :) As for your hypothetical... quite appropriate for a Friday afternoon I think. When comparing an XQL angle to an XSL one, it might be interesting to look at the position paper from the XSL WG on XQL... [QUOTE] For example, a query language generally places more emphasis on: more complex information retrieval the naming and reuse of intermediate query results the ability to perform joins, whether between documents or within a document the ability to retreive information from multiple documents While a stylesheet language normally places more importance on: handling recursive and heterogeneous XML data controlling whitespace numbering and other positional features supporting multiple output documents [END QUOTE] While there are many similarities between the two efforts the focus between the two is markedly different. You see we have a description of transformation within XSL but for XQL people are looking to produce a different description based upon the existing XSL one, rather than simply use the XSL one. So in the scenario you paint it's quite reasonable to run the other way and if XQL pre-existed build an XSL transformative descriptiton based on the existing XQL one. You say ..."Now, it may be just me, but I don't feel that the second alternative would have been even seriously considered, never mind actually being accepted as the dominant solution."... but that is exactly what is being considered, just the other way around. You see producing a language standard isn't just a software engineering exercise involving factoring of isolated parts, it's is more akin to product development or which software engineering is but one part. In delivering a product ones objective is to best meet the specified requirements. Factoring of reusable parts is of course highly desirable (and seems to me to have been the first genuine arguement placed for the separation of XSL-T and XSL-F that I have read, there might be others I've missed), but is not an objective in and of itself, merely a consideration along the way. If factoring can be achieved while still achieving your requirements cool, you get some bonus points. However try and sway a product manager with talk of factoring while trying to explain to them why your product requirements haven't been met and you wont get very far. Worse still, try and convince the customer that unfortunately their requirements wheren't met, but hey, the architecture factors really well and the customers of a different product are getting lots of cool features as a result! Don't be suprised if you loose the customer. I believe the approach of the XQL community to have been a sensible one. They have started from the basis of their own requirements, with their own agenda, and the goal to cross-fertilise with XSL as much as it possible, while still persuing the fulfillment of their own requirements. XSL should I think follow the same sensible approach. Persue it's own requirements, and if other groups can feed off that, I am genuinely pleased, but one shouldn't loose site of the given requirements. And one definately shouldn't confuse the requirements of other products with those of XSL, or worse still mistake the requirements of another product for those of XSL. So I don't think the reason for this discussion is merely for historic reasons, but for reason of good product development, in this case XSL. Cheers Guy. xsl-list@xxxxxxxxxxxxxxxx on 03/05/99 07:35:03 AM To: xsl-list@xxxxxxxxxxxxxxxx cc: (bcc: Guy Murphy/UK/MAID) Subject: Fw: XSL-T, XTL.... or XQL? Guy_Murphy@xxxxxxxxxx wrote: [SNIP] >I've maintianed for a long time now that persuit of a general purpose XML >transformation language would be best done under the >banner of XQL, or at least starting under XQL. Nice try :-) Just as a hypothetical question, though: Suppose that XML was gaining popularity during the 80s instead of the 90s, and that XQL as a way to query/restructure/whatever XML documents was a mature solution by the early 90s. No web, no HTML, just a standard way to represent trees in text files, and to query and transform them to other trees - and even into non-XML formats, mainly for printing (TeX, Rtf, PostScript, etc.). Now comes the web and people want to "style" their XML data for it. Two alternatives arise. Either use the existing XQL to generate some XML formatting language - be it "HTML", "XML+CSS", "FO", or whatever; or create a new language which combined a subset of XQL and a formatting language. Now, it may be just me, but I don't feel that the second alternative would have been even seriously considered, never mind actually being accepted as the dominant solution. It is very likely that browsers would have implemented only a subset of XQL at first, but that would have been accepted as a necessary evil and would have been remedied in time. So, the way I see it, the only reason we have this discussion is a historical accident - XML arriving late at the scene. Share & Enjoy, Oren Ben-Kiki XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Fw: XSL-T, XTL.... or XQL?, Oren Ben-Kiki | Thread | XSL-T, XTL.... or XQL?, Oren Ben-Kiki |
Re: IE5's xsl:copy, Chris Maden | Date | Re: W3C-transformation language pet, Guy_Murphy |
Month |