[
Lists Home |
Date Index |
Thread Index
]
I'll add another essential benefit, somewhat related to (f):
(g) Just drop an XSLT 2.0 schema into an intelligent XML IDE and voilla --
you have a syntax-oriented XSLT 2.0 editor with:
- syntax colouring;
- intellisense;
- autocompletion;
- expand/collapse trees;
- meaningful error messages;
- re-formatting and pretty-printing;
- natural potential to add refactoring;
And you have this the same second you specify the schema!
Not just a theoretical meandring -- I have done this and other people have
done this, too, see for example:
http://norman.walsh.name/2004/07/25/xslt20
Cheers,
Dimitre Novatchev.
"Michael Kay" <mike@saxonica.com> wrote in message
E1CbyBV-0007Wy-00@ukmail1.eechost.net">news:E1CbyBV-0007Wy-00@ukmail1.eechost.net...
>> 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/
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>
>
>
|
