[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Create a special purpose programming language, in XML, usi

  • From: Michael Kay <mike@saxonica.com>
  • To: Norman Gray <norman@astro.gla.ac.uk>
  • Date: Fri, 18 Oct 2013 16:11:47 +0100

Re:  Create a special purpose programming language
> 
> Random observations:
> 
>  * The nastiness may be a strong function of the structure of the XML being processed.  Highly structured and 'orthogonal' XML is going to be a lot nicer to process, with fewer modes and fancy selectors required, but that may be rare.

Certainly true. The template rule mechanism is of course optimized for document structures where the rules tend to be quite lax.
> 
>  * There aren't many up-front structuring/packaging mechanisms within XSLT, to help authors manage and compartmentalise code.  Yes, one can include stylesheets, but that's not importantly different from textual inclusion, so there's not a lot of real packaging here.

Also true. We're trying to address that in XSLT 3.0 with packaging mechanisms.
> 
>  * XSLT is just plain ugly, both in the sense of being 'jaggy' to read on the screen, and being verbose, so that you don't get that much real code onto a screen in an editor window, so that I, at least, find it easy to get lost within a file.  I've whined about this on this list, at various intervals, for about a decade (sorry, people -- I'm still taking the medicine), without anyone showing much sign of agreeing with me.  I've even gone to the extent of creating an alternative syntax, so great was my irritation <http://nxg.me.uk/dist/lx/>, but I've never had many takers.  Oh well....

Well, XSLT 2.0 typically reduces the size to about a third of what it was; sadly there are still lots of people basing their perceptions on XSLT 1.0. For many transformations, the XSLT 2.0 code is very substantially more concise than the same code written in say Java or Perl.

But I think you miss another point, which in my view is the biggest problem in writing substantial stylesheets, and that is the "blank output" problem. If you get things wrong, typically a path expression, you don't get an error message, you get no output. Writing schema-aware stylesheets can go a long way to help there, but for most people it's proved to be too much hassle (up-front effort for deferred benefits; not an easy sell). Of course, most of XSLT's competitors have exactly the same problem, with the exception of data binding, which has its own drawbacks: and unless you are prepared to live with the inflexibility that results from binding your code closely to a schema, there really isn't a good answer.
> 

Michael Kay
Saxonica



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.