Re: Fw: XSL-T, XTL.... or XQL?

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