|
|
 next
|
  Subject: stylusXslt command line -- XSLT 2.0 compatible?
Author: Steven Black
Date: 31 Mar 2008 10:53 PM
|
Thanks for clarifying the positioning and intent of SS. Now I get it. I just assumed I could call the SS command-line utility as part of a simple Me-ware application I'm creating here.
I'm mostly frustrated by my inability to get Saxon .NET set-up here because of an unsigned 3-rd party DLL that apparently found its way into the latest distro. Sorry for the frustration.
THAT SAID, from the perspective of a SS customer, it seems to me that the limitations of the command-line utility should be
1. More up-front, and
2. Certainly clarified
Look at this page, for example:
http://www.stylusstudio.com/docs/v2006/d_start83.html#wp405262
It says:"The StylusXslt utility uses the XSLT and XPath processors specified in Stylus Studio."
As it turns out, that's apparently BS. It's misleading and borderline dishonest.
It has nothing to do with the "Specified" XSLT processor. It should say "the built-in XSLT processor" because, if it worked as it says here, I wouldn't have this issue. The built-in XSLT processor, it turns out, isn't XSLT 2.0-compatible. THAT PAGE SHOULD SAY THAT!
SS isn't a $99 piece of software. It's deluxe. Good deluxe software should not waste hours of its customers' time chasing specifically documented functionality that, clearly, isn't there.
See what I mean? Please, at least document this properly.
|
|
next
|
  Subject: stylusXslt command line -- XSLT 2.0 compatible?
Author: George Willis
Date: 17 Jan 2009 09:15 PM
|
I have to second this point.
It is a great shortcoming in an "enterprise" tool to not allow a stylesheet or xquery to be invoked with both a scenerio parameter, and with additional parameter that override the scenerio settings on the commandline (such as inFile, outFile, or Processor).
The .NetCompiledXSLT processor accomplished in less than 2 secs what it takes 20 secs to do in StylusXslt -- a tenfold increase!!! I do bulk transforms, and since there is no command line for these processors, I cannot deploy using them. Nor can I turn a batch process that takes 30 minutes into one that takes 5 hours!!!!!!
I could deploy if SS would simply add this most basic feature of a full CLI invocation, something I get with 99% of other tool I use, whether "Enterprise" or "Freeware".
This misleading documentation also points to the fact that people inside of the SS organization envisioned the same functionality that someone has chosen NOT to implement. Given how basic this feature is, I am predisposed to consider this a business decision, and not a technical one -- and a poor business decision at that.
I expected more. I expected "Enterprise = Production Ready = Mission Critical". I expected your documentation to truly reflect the capabilities of the product.
I expected simple things to be simple -- and implemented.
Now, I am left to go compile my own commandline .NETCompiledXSLT commandline tool for production. Who should I send the bill to?
>Thanks for clarifying the
>positioning and intent of SS.
>Now I get it. I just assumed
>I could call the SS
>command-line utility as part
>of a simple Me-ware
>application I'm creating here.
>
>I'm mostly frustrated by my
>inability to get Saxon .NET
>set-up here because of an
>unsigned 3-rd party DLL that
>apparently found its way into
>the latest distro. Sorry for
>the frustration.
>
>THAT SAID, from the
>perspective of a SS customer,
>it seems to me that the
>limitations of the
>command-line utility should be
> 1. More up-front, and
> 2. Certainly clarified
>
>Look at this page, for
>example:
>http://www.stylusstudio.com/do
>cs/v2006/d_start83.html#wp4052
>62
>
>It says:"The StylusXslt
>utility uses the XSLT and
>XPath processors specified in
>Stylus Studio."
>
>As it turns out, that's
>apparently BS. It's
>misleading and borderline
>dishonest.
>
>It has nothing to do with the
>"Specified" XSLT processor.
>It should say "the built-in
>XSLT processor" because, if it
>worked as it says here, I
>wouldn't have this issue. The
>built-in XSLT processor, it
>turns out, isn't XSLT
>2.0-compatible. THAT PAGE
>SHOULD SAY THAT!
>
>SS isn't a $99 piece of
>software. It's deluxe. Good
>deluxe software should not
>waste hours of its customers'
>time chasing specifically
>documented functionality that,
>clearly, isn't there.
>
>See what I mean? Please, at
>least document this properly.
|
 top
|
Subject: stylusXslt command line -- XSLT 2.0 compatible?
Author: George Willis
Date: 21 Jan 2009 08:23 PM
|
Some concluding points...
1) I have found the new nxslt3.exe put out by XML Lab (free) that gives you a blazingly fast XSLT command line tool. It will even do compiled XSLT (anyone coming across a command line toll to produce compiled XSLT or the command line switches to make this tool produce, post a response) I cannot say enough about the spped of this tool! (and it handle XINCLUDE, another topic at issue on SSDN)
2) I have found several XQUERY command line tools as well, including a XQUERY to XSL stylesheet that allows you to convert and run XQUERYunder nxslt3.exe (did I mention speed), a new .NET XQUERY tool, GALAX compiled to .NET, and two other tools. (Now that I have my fast xslt, I want my fast and streaming xquery.
3) I've been a developer too long to know how easy it is to create a command pattern in a tool. Given the strength and streaming capabilities of these new engines, it would have been a wiser business decision to give xquery and xslt for the command line away, add, these other more capable engines, and fit the tool for dev and production deployments. You should have learned from Bertand's mistake with Eiffel -- he should have gave the Linux dev environment away 5 years ago, before Ruby stepped in.
4) No hard feeling, and no apologies needed. In fact, one of the things I have found better than your tool is your support. First rate :)
5) Most wanted feature: better management of stylesheet template expand/collapse. I hate that it does not open fully collpapsed, the you don't have expand all/collapse all buttons, and that when I come out of template mode, everything I collapsed is now expanded. Stylesheets get big, and a better XSL editor would be nice. Tied: real streaming in XQUERY without having to write your xquery in alignment with the planets only too find out that certain functions now work differently -- check out deep-equal under a true streaming xquery.
6) Least used feature -- all that visual mapping stuff -- just too confusing.
|
|
|
|
|
