[
Lists Home |
Date Index |
Thread Index
]
> So Dave, we had this argument a couple of times, and I never
> understood
> your answer: what exact benefit do you get from the the fact
> that XSLT is represented in it's current XML syntax ?
I think the benefits are:
(a) many stylesheets consist of two-thirds data to be copied into the result
tree, and one-third instructions to extract data from the source document.
An XML-based syntax is beneficial for the two thirds that is data, because
it means the code in the stylesheet is a template for the final result. This
also facilitates a development approach that starts with graphical designers
producing a mock-up of the target HTML or XSL-FO page, and then handing it
over to a programmer to add the control logic. (XQuery has recognized this
by using an XML-like syntax for element constructors, but there's a lot of
difference between being XML-like and being XML.)
(b) XSLT inherits all the lexical apparatus of XML: entities, character
references, Unicode encoding, normalization of line endings and whitespace,
namespaces, base URI, and whatever the core WG dream up next. That means
there's only one set of rules for users to learn; it means there's a lot
less detail for the WG to reinvent and possibly get wrong; it means users
can take advantage of XML editing tools; and it gives implementors a head
start.
(c) It's surprisingly common, especially in large applications, to see
stylesheets being used as the input and/or output of a transformation. My
favourite example is an online banking system that had 400 screens each
generated by its own stylesheet, but all 400 stylesheets used a common
look-and-feel which was achieved by generating them from a master database
containing rules for all the different kinds of content that could be
encountered. It's not obvious how one would do that in XQuery: one could go
some way with a function library, but not nearly as far (especially without
polymorphic functions). (And since queries aren't XML, I can't even search
for all the queries that invoke a particular function, without a meta query
language!)
(d) One of the original arguments was that for client-side applications,
especially in small-footprint devices, only one parser would be needed
rather than two. However, I've no idea whether this argument stands the test
of time.
(e) XML vocabularies can be nested. We had no difficulty recently adding the
capability to have an inline schema within a stylesheet for describing its
working data, because XSLT and XML Schema are both defined in XML. Similarly
stylesheets can be embedded in other XML documents, for example in the
source document to which they apply, or in a pipeline processing language.
(f) One unpredicted benefit, I think, is that the XSLT syntax ends up being
more systematic, extensible, and robust. It's much easier to add another
attribute to an XSLT instruction than to extend the XQuery grammar, and it's
much easier for a compiler to catch all the syntax errors in one run.
Historically, a lot of the motivation for XSLT being in XML was the
experience of DSSSL, where the unfamiliar LISP-like syntax was widely
regarded in retrospect as the reason for the lack of take-up. It was
intended that XSLT should be writable by non-programmers, and I believe that
often happens. In fact I have heard it said that non-programmers have far
fewer conceptual problems with the language than JavaScript or SQL
programmers do.
>
> And why don't you get the same benefits from XQueryX (the pure XML
> variant of XQuery) ?
Because no one would ever want to author or edit or maintain a query using
that particular language - it's far too low-level.
Michael Kay
http://www.saxonica.com/
|
