replacing a node in in-memory XML

[John Snelson]

Michael Kay wrote:
>>> I there a reason behind your preference or is it just a personal 
>>> preference?  I've always considered XSLT's XML syntax to be an 
>>> advantage when you're adding XML to the result...
>> Or course it's just personal preference, but I think it's a 
>> preference shared by the majority of programmers in the world 
>> - otherwise people would be writing their Java or C++ in XML.
> 
> There are three main benefits that XSLT users get from its XML-based syntax:
> 
> (a) you can move incrementally from authoring to programming. Start by
> writing the XHTML, then take out some of the constants and replace them with
> expressions that calculate the value. There are an awful lot of people who
> have taken this route, and it's often said that non-programmers find it
> easier to learn XSLT than programmers do, for this reason.

The same can almost be said for XQuery too. In practice there are very
few XML documents that aren't also valid XQuery queries.

> (b) you're integrated into the XML environment, you can take advantage of
> all the XML-based tooling that's out there. For example, it tends to be
> easier to store stylesheets in an XML database than to store queries. You
> can embed schemas in stylesheets, stylesheets in XProc, and so on:
> everything fits together.

I can see this, but it seems to be an argument for an XML representation
of a language (think XQueryX) - rather than authoring it in XML.

> (c) you get reflection/introspection for free. Most XSLT-based applications
> of any kind of scale end up taking advantage of the ability of stylesheets
> to process other stylesheets. I can't write a query that processes queries -
> not easily, anyway.

Most programmers gave up on self modifying code a long time ago - so I
can never understand XSLT user's fascination with this. Surely it is
only indicative of a language that isn't powerful enough in the first
place - maybe first class functions would solve this?

> There are also a couple of less obvious advantages:
> 
> (d) it's easier for the language designers to develop and grow the syntax
> and make it extensible, while maintaining stylistic consistency

Yes, true - XML handles schema evolution extremely well. However I don't
think it's worth paying the price of unavoidably ugly syntax in order to
get extensibility.

> (e) it's easier to write processors that produce good compile-time
> diagnostics - that's an inevitable consequence of having more redundancy
> (=verbosity) in the language

I can see how that could happen - but it's this very verbosity that I'm
reacting against.

> Having said that, there's no doubt that there are many tasks where XQuery
> requires fewer keystrokes. But on the whole my experience is that Saxon
> users who start off liking XQuery for its conciseness tend to find
> themselves writing more and more XSLT as the application gets bigger. That's
> not all due to the XML syntax of course - it's probably more because of the
> dynamic template despatch and import precedence, as well as goodies like
> grouping, analyze-string, format-date and the rest.

I agree that templates make complex transformations easier - but I'm
seeing more and more patterns in XQuery that solve 80% of the problem
domain without templates. I think XQuery Update is also going to cut out
a large chunk of transformations that would previously have used XSLT.

Of course, XQuery 1.1 aims to address a number of the other needs you've
mentioned, like grouping and date formatting.

I don't suppose we'd ever the get the hard-core static-typing XQuery
types on board, but I really think adding stylesheet import and
templates to XQuery makes a lot of sense for the kind of domain that
Saxon and XQilla inhabit. The two languages have the same data model -
it ought to be easier to get them to interoperate.

John

-- 
John Snelson, Oracle Corporation
Berkeley DB XML:        http://www.oracle.com/database/berkeley-db/xml
XQilla:                                  http://xqilla.sourceforge.net