[racket] xslt

[DJ]

Ok - new to racket. I would like to use it because I know Common Lisp, but need something that provides good cross-platform gui capabilities. (I can't afford a commercial implementation of CL.)

My software will harvest data from several web services that provide results in xml.

I have spent a half hour searching for info on how to run xslt transforms in racket. All that I can find is a mention that sxml used to have xslt but doesn't any more. I would prefer native racket rather than some kind of ffi solution if possible.

Any suggestions?

Best,

- DJ -

[Neil Van Dyke]

DJ wrote on 02/28/2015 11:49 AM:
> I have spent a half hour searching for info on how to run xslt

> transforms in racket. All that I can find is a mention that sxml /used
> to have/ xslt but doesn't any more. I would prefer native racket

> rather than some kind of ffi solution if possible.

I don't know (I made my own transformer languages back when I did more
XML), but you can try looking at Oleg Kiselyov's documents about SXML
transformation, at:
http://okmij.org/ftp/Scheme/xml.html#SXSLT-examples

With that knowledge, then either:
* wait for someone (John Clements?) to speak up and say they've packaged
that code of Oleg's;
* grep the source of the available SXML-related Racket packages to see
which has Oleg's definitions, and the exact names; or
* turn Oleg's code from his site into a new Racket package.

I wouldn't use FFI at all; I suspect that SSAX and SXML are better than
anything one could get through FFI.

(I think there's been a lot less industry interest in XML than there
used to be, thanks to JSON, and thanks to current framework tutorials
that no longer push XML much. Plus, there are accidents behind why
Racket didn't happen to have well-documented packages of Oleg's stuff
over 10 years ago. The good news is that Oleg did great work on XML in
Scheme, and his code can be used in Racket with just a little trouble.
One of my consulting clients has been using some of the SXML tools
constantly in production for a decade now: Oleg's SSAX, Oleg's SXPath,
Jim Bender's sxml-match, and some custom stuff.)

Neil V.

____________________
Racket Users list:
http://lists.racket-lang.org/users

[Matthew Butterick]

It's not clear whether you already have XSLT transforms that you want to use in Racket, or if you're mentioning XSLT just because it's a method of parsing & transforming XML. If the latter, then you may find that using native Racket data structures (esp. the X-expression) and native XML-friendly functions (like `match`) is more convenient.

[DJ]

Thanks for the reply.

I have a suite of xslt transforms already done, so it would be easiest to run them as is.

That said, the xslt transforms are a small fraction of the total work that I have already done on the application in Common Lisp. It will of course be a substantial effort to convert it to racket; in fact it may be a time to redesign the application from scratch. The most important consideration is that I would now like to support Windows and OS X as well as linux. The business logic (in lisp) runs on all three but the gui part does not. I could do it as a web app run from a linux server, but I would prefer not to do it that way. My other obvious option is clojure, I guess. If I could justify the expense of purchasing LispWorks or Franz Lisp I would, but - too expensive for my pocketbook.

I know that xml and xslt do not enjoy the favor they did fifteen years ago. But then, I already went through the learning curve back then with xslt and xpath, so there's that.

Basically I am trying to assess the effort that will be required to do the project in racket or clojure, and the xslt thing is small but significant part of it.

Thanks again.

Best,

- DJ -

[Neil Van Dyke]

Matthew Butterick wrote on 02/28/2015 06:49 PM:
> If the latter, then you may find that using native Racket data
> structures (esp. the X-expression) and native XML-friendly functions
> (like `match`) is more convenient.

Either SXML or X-expressions are OK for most purposes.

But, IMHO, SXML is somewhat better than Racket X-expressions for most
purposes.

I tried X-expressions a few years ago, to try it while rapidly coding a
research Web app, and it was OK for that purposes. But before and since
then, I've ended up preferring SXML for various XML and HTML work.

I think the hurdles to SXML use in Racket are:
* the libraries are not always neatly packaged, nor documented as
libraries; and
* X-expressions are in official Racket, perhaps because they were
already used for the old DrScheme documentation browser(?) before SXML
caught on with everyone else, so people looking now assume that
X-expressions are the way to go.

FWIW, I put some specification and coding work into trying to unify SXML
and Racket X-expressions. In the end, I decided that SXML's decisions
on things like splicing -- which I originally thought were messy, and
unnecessarily hard to implement in general-purposes SXML libraries --
turned out to be better design decisions for practical use. For
example, regarding splicing for efficient (immutable) manipulation,
after I implemented a splicing construct in the unified language, I
decided that Oleg's original approach was more elegant in practice. So
I threw out that unified stuff, and ended up with just a few small
tweaks to SXML.

Neil V.

[Matthew Butterick]

On Sat, Feb 28, 2015 at 4:45 PM, Neil Van Dyke <ne...@neilvandyke.org> wrote:

* X-expressions are in official Racket, perhaps because they were already used for the old DrScheme documentation browser(?) before SXML caught on with everyone else, so people looking now assume that X-expressions are the way to go.

"Caught on with everyone else"? When I looked into SXML a couple years ago, it seemed like it was already somewhere between dying and dead. [1] I'm not looking to pry it from anyone's fingers. But since I started using Racket, I've never been disappointed by doing things the Racket Way (even if it required some bullet-biting at the outset). X-expressions have never let me down. [2] [3]

[1] http://sourceforge.net/p/ssax/mailman/ssax-sxml/

[2] http://pkg-build.racket-lang.org/doc/pollen/second-tutorial.html?q=x-expression#%28part._.X-expressions%29

[3] http://pkg-build.racket-lang.org/doc/txexpr/

 

[Neil Van Dyke]

Matthew Butterick wrote on 02/28/2015 11:19 PM:
>
> "Caught on with everyone else"? When I looked into SXML a couple years
> ago, it seemed like it was already somewhere between dying and dead. [1]

No, SXML is alive and well. One paragraph... And I was speaking of
when Scheme people went one way, and PLT core kept their own thing (was
it originally from the DrScheme Help Desk, which was a sub-Mosaic
browser?). Although some Racket users have been using SXML despite
that. The ssax-sxml list is not really active anymore, but that doesn't
reflect on SXML. (The keeping-up-appearances-on-some-social-media-site
metric works better for dotcoms. That email list was not where SXML
happens, anyway, and no IPO-lottery-entrant is trying to make that email
list look active to woo other dotcommers.) Oleg moved from Scheme to
Haskell, so I don't think he'll be doing any more Scheme SXML work, but
the SXML design and the tools, like the first-rate SSAX, are already
written. If you scour the last dozen years of Racket list email, you'll
see hints of SXML gaining users because the X-expression universe wasn't
up to users' needs. There is also still some SXML evolution going on,
such as with my tweaks to SXML, my template package
"http://www.neilvandyke.org/racket-html-template/", and a more recent
package called "sxml-destructure" that I'm trying to get open-sourced.
If you check PLaneT, you'll see that the SXML-related PLaneT packages
had tens of thousands of downloads. Since then, a core Racket person
has gone to the trouble to package some of the SXML tools for the new
Racket package system.

> But since I started using Racket, I've never been disappointed by
> doing things the Racket Way

Who is defining "the Racket Way" in this case? Wouldn't a good
definition be "practices that the Racket user community values"?
Inclusion of an API in the default Racket distribution doesn't mean
that's the way that the Racket user community thinks things should be
done; it just means that API is in the default distribution, at this
time, for whatever reason.

As I said, the X-expressions are OK for most purposes, and I'm not
discouraging their use, and I'm not trying to get SXML into the default
distribution. But I and some others think that the SXML universe is
generally a bit better than the X-expression universe, and have found
that using SXML with Racket is totally viable and believed worthwhile.
So maybe people looking to do HTML and XML with Racket should know that.

I definitely wouldn't chase everyone away from SXML, and if I think
there is any chasing-away from SXML in error, then I will pause season 3
of "House of Cards" on a Saturday night, to un-chase-away people from SXML.

[Matthew Butterick]

On Sat, Feb 28, 2015 at 9:43 PM, Neil Van Dyke <ne...@neilvandyke.org> wrote:

But since I started using Racket, I've never been disappointed by doing things the Racket Way

Who is defining "the Racket Way" in this case?  Wouldn't a good definition be "practices that the Racket user community values"? Inclusion of an API in the default Racket distribution doesn't mean that's the way that the Racket user community thinks things should be done; it just means that API is in the default distribution, at this time, for whatever reason.

I was simply reiterating a compliment to the Racket development team that I have made elsewhere [1]. For a new user, the default Racket libraries offer a wealth of useful material, X-expressions among them. As a still newish user of Racket, I have learned to try it Their Way before insisting on having it My Way (or looking for other options farther up the Highway).

[1] http://practicaltypography.com/why-racket-why-lisp.html 

[Neil Van Dyke]

Matthew Butterick wrote on 03/01/2015 08:07 PM:
> As a still newish user of Racket, I have learned to try it Their Way
> before insisting on having it My Way (or looking for other options
> farther up the Highway).

Yes, a newbie should usually try doing things the Racket Way first.

This guidance is especially helpful when the Racket Way is
counterintuitive to the newbie (simple examples: snuggling parens, using
mutations a lot less).

Two caveats:

* A newbie can't always tell what's the Racket Way, nor whether there
even is an applicable Racket Way.

* Racket is not a cult. And there is no ladder in the middle of the
room, beneath some bananas.

[John Clements]

On Sat, Feb 28, 2015 at 11:23 AM, Neil Van Dyke <ne...@neilvandyke.org> wrote:

DJ wrote on 02/28/2015 11:49 AM:

I have spent a half hour searching for info on how to run xslt transforms in racket. All that I can find is a mention that sxml /used to have/ xslt but doesn't any more. I would prefer native racket rather than some kind of ffi solution if possible.

I don't know (I made my own transformer languages back when I did more XML), but you can try looking at Oleg Kiselyov's documents about SXML transformation, at:
http://okmij.org/ftp/Scheme/xml.html#SXSLT-examples

With that knowledge, then either:
* wait for someone (John Clements?) to speak up and say they've packaged that code of Oleg's;
* grep the source of the available SXML-related Racket packages to see which has Oleg's definitions, and the exact names; or
* turn Oleg's code from his site into a new Racket package.

I wouldn't use FFI at all; I suspect that SSAX and SXML are better than anything one could get through FFI.

Ooh! Ooh! "I've packaged that code of Oleg's".

More specifically, I'm mildly embarrassed to report that it took me 20 minutes to determine for sure that in fact the sxml package already contains "that code of Oleg's"; I see that the documentation made no explicit mention of SXSLT, and I've now repaired that.

With that said, SXSLT does not carry out XSLT transformations; instead, it defines its own similar language. If you have a sizeable library (hundreds of transformations? thousands of transformations?) that aren't all slight variations on the same thing, you'd probably be better off using an existing XSLT implementation. If you have only a few, or if they're all small variations on the same thing, I would urge you to consider using something like

SXSLT.

If you'd care to show one such transformation (and I fully understand why you might *not* wish to do so), it would be easier to gauge the difficulty of the translation.

Best,

John