Re: [xsl] XSLT 2.0: Schema-aware processor: What are the compelling advantages over a non-SA processor?

[Justin Johansson <procode@xxxxxxxxxx>]

Thanks to Abel and Michael et. al. who have responded on this one.

>Justin Johansson wrote:
>> To continue on my journey of XSLT enlightenment, I'd like to know what the
>> compelling reasons are to use an XSLT 2.0 schema-aware processor.  Is Dr.
>> Kay's/Saxonica'a the only one out there?

Abel asked:
>Do you have a background in general programming? Remember the time that 
>GOTO was declared dead and procedural programming came along? Remember 
>when around 1993 (smalltalk addicts will give an earlier date I am sure) 

Yes, well, I remember programming on Adelaide Uni's Control Data Corp 6400
10-character word based machine with Hollerith punch cards and, guess one
may say, I've dabbled in a few more programming exercises since then :-)

>It is like many of those discussions: a more structured language will 
>help a poor programmer, whereas a less structured language will work 
>against him/her. A good programmer can still make a rather good program 
>with a poor or weakly typed language, but this same good programmer will 
>know how to benefit from the added features that a strongly typed 
>language brings.

Agree; it is one of those discussions but still an important one.  I reckon
my vintage 8086 and 68020 assembly days smelt more of OO than many of the
C++ programming artefacts I've had the displeasure of reviewing in $mill.
gov. contracts.  So on that I alone I probably do not need SA to make my
XSLT programs better*.  Still, at the end of the day I would like to have a
dot-point list of 6 compelling reasons to sell XSLT Schema-Awareness to my
next manager more so in manager-speak thank geek-speak.

*But saving on debugging time would be valuable.

After reading Michael Kay's response my dot-points are starting to look
something like this:
(Hey, all project managers want to hear about the impact on the bottom line.)

1. Good software engineering; proven design-by-contract yields maintenance
benefits and therefore tangible time & $ savings.

2. Faster coding/debugging cycle and therefore tangible time & $ savings.

3. Increased chance of delivering bug-free code on delivery to client.

4. Perfomance gain spin off through SA optimisation therefore gives our
project an edge over competitor X.

5. If we use SA, the maintenance contract with our client will be money for
jam.

6-10.  More one compelling oneliners welcome.