OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: What niche is XQuery targeting?

[ 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:



Dimitre Novatchev.

"Michael Kay" <mike@saxonica.com> wrote in message 
>> 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>


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS