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


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] What niche is XQuery targeting?

[ Lists Home | Date Index | Thread Index ]

Dear Michael,

Discussions about syntax are what they are. I understand you seem to see 
general advantages in XML syntax. If this is so, I disagree.

XSLT is a powerful tool, and it is focussed on a particular task (and it 
does it well). But stylesheet transformations are hardly a substitute 
for a general purpose programming. I don't think your arguments carry 
over to other languages than XSLT.

Since general purpose programming languages exclusively use non XML 
syntax, it is worth to see how rational XML syntax would be for such a 
general purpose programming language.

Michael Kay wrote:

>>So Dave, we had this argument a couple of times, and I never 
>>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
granted, copy-and-pasting XML into your code is nice, but one can 
combine XML syntax and nonXML code syntax. Actually there are many 
efforts to cut a programming language for native XML processing that go 
this way (apart from XQuery, check e4x, Scala).

>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
Lexical analysis does not pose a deep problem, from my experience the 
only hard thing is in getting the data model right (e.g. in the case of 
Scala, I chose to leave away namespace nodes and prefixes from the 
infoset, but that was not wise at all, because now my students want to 
deal with XSLT stylesheets and will have troubles because of QNames in 

QNames in content need not be an issue for XML data that is written in 
the programming language (it can rely on expanded names for instance and 
string variables for instance). Mixing syntax and semantics in the way 
XSD and XSLT do is not always a benefit. Which kludges are necessary to 
generate an XSLT stylesheet with XSLT? Instead, writing a Java compiler 
in Java is not different from writing a web server in Java.

>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
>(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
This just shows that XSLT is not really modular as a programming 
language. If a readable generic stylesheet could have dealt with the 400 
cases, there would have been no need for this program generation clumsiness.

>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
Every programming language that has gained enough acceptance comes with 
tools that work on programs. Just look at how many Emacs modes there 
are. C programs come with myriads of tools for cross referencing, 
debugging, verification etc. There are probably more tools that 
manipulate C sources than tools that manipulate XSLT. Of course parser 
generation helps here.

>(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.
Also in a hybrid XML, nonXML syntax, you have only one parser. There 
would be less code, on the other hand the programs get shorter, it's a 
tradeoff which is likely to matter only in highly specialized applications.

>(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.
This argument leads to the question of a non-XML syntax for XML Schema 
arises and we return to the discussion we are undertaking.

>(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.
Sure, basically the programmer already writes the abstract syntax tree 
himself, but he pays with verbosity.
The ease of the compiler writer should not guide the design. It's the 
ease of the programmer that counts.

>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. 
Fair enough, but focussing on the audience can also serve as argument 
for non XML syntax.

>>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.
Yeah, not low-level, XQueryX is a joke. It is as bloated as the concrete 
syntax tree that guides an XQuery parser. No reasonable programming 
language with a nonXML syntax would make use of concrete syntax trees 
(and thus no parser ever really generates them).

Abstract syntax instead is very real, and context-free syntax and 
context-free parsing in general are quite well-understood topics. One  
should not condemn them without a good reason. I think there is no 
compelling reason to prefer one syntax over the other. There is just 
preference based on intended field of application and programmer audience.


Burak Emir



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

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