XML Editor
Sign up for a WebBoard account Sign Up Keyword Search Search More Options... Options
Chat Rooms Chat Help Help News News Log in to WebBoard Log in Not Logged in
Show tree view Topic
Topic Page 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Go to previous topicPrev TopicGo to next topicNext Topic
Postnext
Steven  BlackSubject: stylusXslt command line -- XSLT 2.0 compatible?
Author: Steven Black
Date: 29 Mar 2008 10:30 PM
Originally Posted: 29 Mar 2008 10:27 PM
Hi, first post.

I have an XSLT Transform that works great in the SS user interface but when I run it with a command-line call to stylusXSLT.exe it produces bizarre results that, apparently, completely ignore <xsl:for-each-group ...> statements.

items.xml and items6.xsl attached.

I'm using SS 8.0 Enterprise.

Any insight? Thanks!

**--** Steve

Postnext
(Deleted User) Subject: stylusXslt command line -- XSLT 2.0 compatible?
Author: (Deleted User)
Date: 31 Mar 2008 06:48 AM
Hi Steven
the StylusXSLT command line tool wraps the "Built-in" processor, that is only able to process XSLT 1.0 stylesheets. As the only XSLT 2.0 processor is Saxon, you should run it from the command line as documented at http://www.saxonica.com/documentation/using-xsl/commandline.html

Hope this helps,
Alberto

Postnext
Steven  BlackSubject: stylusXslt command line -- XSLT 2.0 compatible?
Author: Steven Black
Date: 31 Mar 2008 10:44 AM
Thanks Alberto. I'll give that a try.

In particular, thank you for pointing out the correct page on the Saxonica website, which I find somewhat dysfunctional.

Postnext
Steven  BlackSubject: stylusXslt command line -- XSLT 2.0 compatible?
Author: Steven Black
Date: 31 Mar 2008 09:41 PM
Alberto, it turns out that Saxon.net isn't an option right now because of an unsigned version of IKVM.GNU.Classpath.dll that cannot be added to the .NET GAC in their current distribution package.

You know, it's a real "hole in the product" that the command-line transformation doesn't work with XSLT 2.0, and leaving Stylus Studio customers to navigate the treacherous time-wasting open-source solutions is doing nobody any favors.

I actually wasted quite a bit of time with the wholly reasonable assumption that if SS can make something work in the UI it can also make it work with the command line interface. Wrong.

It's actually quite frustrating to get a substantial piece of work working perfectly in the SS UI only to be totally marooned upon implementation.

If the UI can bridge, why can't the command-line? Really frustrated.

**--** Steve

Postnext
Minollo I.Subject: stylusXslt command line -- XSLT 2.0 compatible?
Author: Minollo I.
Date: 31 Mar 2008 09:50 PM
I'm not sure how different it would be to make the Stylus Studio command line invoke the Saxon XSLT 2.0 processor (either Java or .NET) vs. running the Saxon command line explicitly (Java or .NET); am I missing something?

If your request is to make the built-in processor XSLT 2.0 compliant, we understand that; but that's not going to happen anytime soon. Stylus Studio is a development environment that lets you deploy applications on runtime components like DataDirect XQuery (our preferred choice) or Saxon XQuery and XSLT (Java or .NET). The XSLT and XQuery built-in processors in Stylus Studio are meant almost exclusively for debugging/development purposes; the command lines are a small convenience that lets you access the same processor from batch processors; but it surely not meant to provide a complete deployment option.

Postnext
Steven  BlackSubject: 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.

Postnext
Minollo I.Subject: stylusXslt command line -- XSLT 2.0 compatible?
Author: Minollo I.
Date: 31 Mar 2008 11:05 PM
Is there any reason why the Saxon Java command line wouldn't work for you? That won't force you to load any .NET assembly, of course.

Again, if the Stylus Studio command line worked as you expect (and yes, as the documentation mis-leadingly hints), it would run the processor specified in the scenario properties of your XSLT; which, in the case of XSLT 2.0, could only mean Saxon (Java, specifically).

Postnext
Steven  BlackSubject: stylusXslt command line -- XSLT 2.0 compatible?
Author: Steven Black
Date: 01 Apr 2008 08:34 AM
>> Is there any reason why the Saxon Java command line wouldn't work for you?

Because
1) I'm not a Java developer and
2) I was going to call this command-line from a non-Java application.

>>...it would run the processor specified in the scenario properties of your XSLT; which, in the case of XSLT 2.0, could only mean Saxon (Java, specifically).

Are you telling me this XSLT won't run with the Saxon .NET parser?

Postnext
(Deleted User) Subject: stylusXslt command line -- XSLT 2.0 compatible?
Author: (Deleted User)
Date: 01 Apr 2008 11:28 AM
Hi Steven,
if your application is designed to launch an external process like StylusXSLT.exe, it can also launch the java.exe process with the "net.sf.saxon.Transform -s:source -xsl:stylesheet -o:output" arguments, without the need of writing a single line of Java code.
As for the comment by Minollo, he was referring to the fact that the Stylus IDE only runs the Java version of Saxon, not the .NET version; so, even if StylusXSLT were able to invoke Saxon, this would not be the .NET version.

Hope this helps,
Alberto

Postnext
Steven  BlackSubject: stylusXslt command line -- XSLT 2.0 compatible?
Author: Steven Black
Date: 01 Apr 2008 12:10 PM
Originally Posted: 01 Apr 2008 12:09 PM
Thanks! Now THAT's a great piece of information. Thank you very much.

I've never invoked a Java command-line process before. That's cool! (sound of slap on forehead).

You know, as developers, we tend to stay in silos. Java's just not my bag. Just the thought of spelunking into a huge haystack looking for a (obvious) needle like this was a non-starter...

You know, assuming the StylusXSLT.exe online docs will be clarified, it might be a nice touch to add a couple of pointers related to this. I sense that getting XSLT 2.0 transforms into production might become an increasingly frequent question here.

Thanks again Alberto!

**--** Steve

Postnext
George WillisSubject: 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.

Postnext
Steven  BlackSubject: stylusXslt command line -- XSLT 2.0 compatible?
Author: Steven Black
Date: 17 Jan 2009 10:32 PM
Absolutely, George.

I complained about this NINE MONTHS AGO and the friggin' documentation STILL hasn't been corrected.

So bush.

**--** Steve

Postnext
(Deleted User) Subject: stylusXslt command line -- XSLT 2.0 compatible?
Author: (Deleted User)
Date: 20 Jan 2009 11:26 AM
Steve and George. I'm sorry for any confusion or troubles you experienced resulting from the documentation. I am responsible for this oversight, and I'll make sure that it is addressed in the next Stylus Studio release.

David Foster
XML Products Team

Postnext
Ivan PedruzziSubject: stylusXslt command line -- XSLT 2.0 compatible?
Author: Ivan Pedruzzi
Date: 20 Jan 2009 04:22 PM
Hi George,

Did you consider the C# code generation feature in the XSLT editor or in the pipeline designer?

Thanks
Ivan Pedruzzi
Stylus Studio Team

Posttop
George WillisSubject: 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.

 
Topic Page 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Go to previous topicPrev TopicGo to next topicNext Topic
Download A Free Trial of Stylus Studio 6 XML Professional Edition Today! Powered by Stylus Studio, the world's leading XML IDE for XML, XSLT, XQuery, XML Schema, DTD, XPath, WSDL, XHTML, SQL/XML, and XML Mapping!  
go

Log In Options

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