XSL-T, XTL.... or XQL?

Guy_Murphy@xxxxxxxxxx wrote:
>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...
>
>While there are many similarities between the two efforts the focus between
>the two is markedly different.


Actually it seems as though XSL is a proper subset of XQL.

>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.

Given XSL < XQL, it is obvious one would need to do that.

>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.


Given XSL < XQL, it doesn't follow that we'd bother to define the XSL subset
as a separate language.

>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.


Again, a necessity given XSL < XQL, redundant 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.


Getting the requirements right is also important :-) It is also important
not to give the user two 80% compatible solutions, so that only by using
them together he can get what he needs.

Have fun,

    Oren Ben-Kiki.


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list