[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: What niche is XQuery targeting?
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@s...> wrote in message E1CbyBV-0007Wy-00@u...">news:E1CbyBV-0007Wy-00@u...... >> 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> > >
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|