commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul Akolkar <>
Subject Re: [scxml-js][all] seeking guidance on layout of XSLT-based project
Date Sun, 13 Jun 2010 00:17:52 GMT
On Fri, Jun 11, 2010 at 10:56 PM, Jacob Beard <> wrote:
> Hi,
> Over the last two weeks, I've done some major refactoring to the
> scxml-js project. Primarily, I've moved some code around to make the
> architectural components more pure, and I've change the primary
> implementation language from JavaScript and E4X to XSLT. I think it
> would be useful to resume the dialog about how the scxml-js project
> layout should be structured.
> Right now, there are three main components:
> * a front-end which is responsible for accepting compiler options and
> SCXML documents, and invoking the middle tier and back-end components
> * a middle tier, which implements the main compiler logic, and is
> responsible for generating an intermediate representation (IR) which
> is easy to generate code from
> * various back-ends, which accept the IR and generate executable code
> in a particular programming language.
> There are two languages currently used in implementation of scxml-js:
> * The middle tier and JavaScript back-end are implemented entirely in XSLT.
> * The front-end is currently implemented in JavaScript, targeting
> Rhino. This is a very thin layer, though, and could be implemented in
> any language, from bash to Java. However, a JavaScript front-end will
> be needed when targeting the browser environment, so it might just
> make sense to maintain only one front-end, and have it be written in
> JavaScript.
> The scxml-js build system is still written in JavaScript, targeting Rhino.
> I'm now trying to determine how a multi-language, but primarily
> xslt-based project could best be structured. In particular, it's still
> unclear to me whether Maven would be able to play useful role in this
> project.

Yes, unclear from a build and test point of view. Though at the least,
Maven will be useful for:

(a) Creating and deploying a website with the Commons look and feel
(b) If and when any of the code is ready for a release, it will help
with the release mechanics (creation of distros, staging etc.)

I intend to add simple websites for the GSoC projects soon (so there
will be a Maven POM in place for the site, and we can see if that can
evolve the Maven build into something more useful over time).

> I'm currently only aware of one other project where the primary
> implementation language is XSLT, and that's Docbook:
> It's difficult to understand at a glance out how Docbook is
> structured, however.

You've probably pasted the scxml-js trunk URL above in error. In any
case, another project that has an XSLT impl, is meant for execution in
web browsers and implements a W3C spec is XSLTForms:

Given the similarities, might be useful to look at it.

> For right now, I'd like to propose that I keep the project structured
> the same as it is now (see
> but add the following directories to store the xslt middle tier and
> back-end:
> src/
>        xslt/
>                ir-compiler/
>                backends/
>                        js/

Seems reasonable at the moment (I see you've checked in code along these lines).


> If anyone has any ideas about this, I'd greatly appreciate it if you
> could let me know. Thanks,
> Jake

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message