A SaxonC 12.4.2 maintenance release has been published. This release fixes several issues:
Some efforts have also been made to improve the way dynamic libraries are referenced when using the C/C++ APIs directly. These changes are reflected in the builds and in the scripts that compile the “command” and “samples” applications.
In brief: on macOS, the dynamic library can be accessed through
@rpath
and on Linux, the dynamic library can be placed in a standard
location or accessed with the LD_LIBRARY_PATH
environment variable.
On Windows, apparently the standard practice is to place the DLL in the same
directory as the executable.
For a more complete list of what’s new in 12.4, please see the original release announcement and the SaxonC release notes on the main website.
A SaxonC 12.4.1 maintenance release has been published. This release fixes a build error on the Windows platform and includes one additional patch.
I’m an ardent believer in build automation and reproducibility through scripting. We’ve made a lot of progress in this area, but Windows is still a bit “hands on.” Problem is, it was my hands and I messed up.
A while back, we considered upgrading to a newer version of GraalVM. In the course of testing that, I upgraded the version on the Windows build machine. But ultimately, we decided not to make that upgrade.
Despite having an explicit note in my release checklist:
I missed it on the Windows box. A lot of good detective work went into trying to figure out what was going on, but in the end, just building with the “right” version of GraalVM fixed it. Apologies to the team and everyone else for that.
The 12.4.1 release also includes a partial fix for issues relating to UTF-8 string-based C API functions. Unfortunately, a more complete fix was deemed too risky for what was otherwise an “emergency” release. That fix will have to wait for next time.
For a more complete list of what’s new in 12.4, please see the original release announcement.
The Saxon 12.4 maintenance release has been published. This is a maintenance release for Java, C#, C/C++, PHP, and Python that fixes a number of issues reported since the Saxon 12.3 release. (Note: A 12.4.1 maintenance release of SaxonC was published on 1 December 2023.)
Saxon 12.4 was released on 29 November 2023. This release has been uploaded to the usual locations on the Saxonica website, GitHub, and Maven, PyPi, and NuGet. SaxonCS 12.4 is built with .NET 6. This release includes SaxonC and Python releases for the ARM 64 architecture as well as X86-64 architecture.
For a list of the issues resolved in this release, please visit the issue trackers for SaxonJ and SaxonCS or SaxonC on the Saxon support site.
Download products:
For more details, please consult the documentation.
This section is a subset of the complete list of resolved issues. It’s curated to bring attention to the bugs that seem most likely to impact customers.
For a full list, see the issue tracker.
schema-element(*:foo)
xs:alternative
xsl:evaluate/@context-item
expression is present, but evaluates to empty sequenceFor a full list, see the issue tracker.
thisxqptr
If you encounter any issues with Saxon 12.4, please report them on our issue tracker.
The SaxonJS 2.6 maintenance release has been published. This is a maintenance release for NodeJS and the browser. It fixes more than a dozen bugs (including that one about the spurious warning message). Highlights include:
For a complete list of the issues resolved in this release, please visit the issue tracker on the Saxonica support site.
SaxonJS 2.6 was released on 13 October 2023. This release has been uploaded to the usual locations on the Saxonica website and the NPM repository. For more details, please consult the documentation.
If you encounter any issues with SaxonJS 2.6, please report them on our issue tracker.
TL;DR, you can ignore the message.
Several folks have noticed that, since about yesterday, if you run
the SaxonJS 2.5 xslt3
Node.js command line processor, it
prints a scary “no longer supported” message.
Sorry. Our bad. The message is only informative and has no effect on the performance of the processor.
We support SaxonJS releases for at least a year and a while back (far enough back that I can’t easily determine when from the repository history), we confidently assumed that we’d always do a release at least once a year. So when you got that message, it was to encourage you to upgrade.
Except this year, we published a whole bunch of other releases, embarked on SaxonJS 3.0, shifted our web infrastructure around, and did a bunch of other things. What we didn’t do was publish SaxonJS 3.0 within a year, and because we were heads-down on that, we didn’t notice that we hadn’t published a SaxonJS 2.6 release within a year either.
(It’s all a little embarrassing.)
We’ve fixed a handful of bugs in SaxonJS 2.5 since we shipped it, and we’ve identified a slightly larger handful that we’d like to consider fixing before we ship a SaxonJS 2.6 release. But we will ship it, as quickly as practical.
As Mike says, today is a big day. It is an honour to be able to announce that I am taking on a new role as CEO of Saxonica.
Let me start by offering huge congratulations and thanks to Mike and Penny Kay, whose talent, commitment, and hard work have made Saxonica into the successful company it is today.
I’m happy (and somewhat relieved!) to say that the Saxonica team will continue to benefit from Mike’s experience for the foreseeable future, as he moves to a new role as Director of Innovation. Working part-time, Mike will continue to support customers and colleagues alike, as well as ensuring that his in-depth knowledge of our code base continues to be passed on to the rest of the Saxonica engineering team, myself included!
Before I had the opportunity to join the company in 2020, I was already an enthusiastic part of Saxonica’s user base. I know how important our products are to our users; I am one of our users!
Working with this team of talented people to develop software that makes a real contribution to the XML community has been a privilege. Becoming Saxonica’s CEO is an even greater one. I am committed to seeing Saxonica grow and prosper into the next decades, continuing the reputation for excellence, innovation, and community-mindedness that Mike has worked so hard to establish.
Under the hood, Saxon uses a “resolver” whenever it attempts to load a document (a source document, stylesheet module, unparsed text document, etc.). For the past few releases, the Java, C#, and C products have been using resolvers based on the XML Resolver APIs.
I’ve been working on some improvements to those APIs. It’s likely that the next releases of Saxon will be ship with XML Resolver 6.x.
If you’d like to preview the planned changes and provide feedback about how they work in your applications, that’d be grand.
Just FYI, we’ve moved some things around. Some of our web infrastructure, the way www.saxonica.com and dev.saxonica.com are served, for example, has changed. Plus we have some new infrastructure for downloads and Maven.
You aren’t supposed to notice. Or, at least, it isn’t supposed to be broken. There are redirects in place for things we know moved and a few very old things have fallen by the wayside.
If you see something that you think is broken, please tell us!
The Saxon 11.6 maintenance release has been published. This is a maintenance release for Java, C#, C/C++, PHP, and Python that fixes almost 40 issues reported since the 11.5 release.
Saxon 11.6 was released on 24 August 2023. This release has been uploaded to the usual locations on the Saxonica website, GitHub, Maven, and NuGet. SaxonCS 11.6 is built with .NET 6.
For a list of the issues resolved in this release, please visit the issue tracker on the Saxon support site.
Download products:
For more details, please consult the documentation.
If you encounter any issues with Saxon 11.6, please report them on our issue tracker.
We’ve recently discovered a small discrepancy in how we manage the dependencies between ICU4J and SaxonJ EE.
If you download the EE release from our website, you get a distribution that includes SaxonJ EE, XML Resolver, ICU4J, and JLine (used by Gizmo). The manifest in the SaxonJ EE jar file puts those additional dependencies on your classpath automatically.
If you get the EE release from our Maven repository, ICU4J is an optional dependency. So Maven won’t automatically put it on your classpath. That’s the discrepancy.
Saxon EE will function without ICU4J, so it is technically optional. I’m unsure which would be better: making it optional in both places or non-optional in both places. Having it different certainly seems like the worst choice and we should fix it.
In the short term, if you’re using Saxon EE and you want the collations supported by ICU4J, make sure you’re also arranging for ICU4J to be on your classpath.
We discovered this in the course of examining issue #6183. For slightly complicated reasons involving our type hierarchy, if ICU4J is missing, you can get an error message that suggests you’re running Saxon HE even when you’re running EE. We’ll fix that too.
Historically, we’ve used a customized version of JELDoclet to generate XML from Javadoc. We use the XML to construct parts of our website. The Javadoc APIs used by JELDoclet (and all of the other Javadoc-to-XML doclets that I could lay my hands on) have been deprecated as of Java 9 and will eventually be removed from the JDK.
On a whim last weekend, I took a stab at simply rebuilding an XML doclet on top of the new Javadoc APIs. You can find the results of that effort in the xmldoclet repository.
It’s only version 0.1.0, but I think it’s broadly functional. It handles all of the sources I’ve thrown at it, including the Saxon Java products which are fairly large and complex. If you try it out and discover that it produces output that seems incomplete or incorrect, please open an issue.
I can’t say I’m especially fond of the Javadoc APIs. In particular, although you need to know what imports a class has in order to correctly resolve the names of types, the public APIs provide no access to that information. In the end, I applied an old maxim:
If brute force doesn’t work, you’re not applying enough brute force.
I simply included the Java parser that we use for the transpiler and parse the sources myself.
Comments most welcome…
The Saxon 12.3 maintenance release has been published. This is a maintenance release for Java, C#, C/C++, PHP, and Python that fixes a number of issues reported since the Saxon 12.2 release.
Saxon 12.3 was released on 4 July 2023. This release has been uploaded to the usual locations on the Saxonica website, GitHub, and Maven, PyPi, and NuGet. SaxonCS 12.3 is built with .NET 6. This release includes SaxonC and Python releases for the ARM 64 architecture as well as X86-64 architecture.
For a list of the issues resolved in this release, please visit the issue trackers for SaxonJ and SaxonCS or SaxonC on the Saxon support site.
Download products:
For more details, please consult the documentation.
This section is a subset of the complete list of resolved issues. It’s curated to bring attention to the bugs that seem most likely to impact customers.
For a full list, see the issue tracker.
dlopen@GLIBC_2.34
If you encounter any issues with Saxon 12.3, please report them on our issue tracker.
The Saxon 12.2 maintenance release has been published. This is a maintenance release for Java, C#, C/C++, PHP, and Python that fixes a number of issues reported since the Saxon 12.1 release.
Saxon 12.2 was released on 2 May 2023. This release has been uploaded to the usual locations on the Saxonica website, GitHub, and Maven, PyPi, and NuGet. SaxonCS 12.2 is built with .NET 6. This release includes SaxonC and Python releases for the ARM 64 architecture as well as X86 64 architecture.
For a list of the issues resolved in this release, please visit the issue trackers for SaxonJ and SaxonCS or SaxonC on the Saxon support site.
Download products:
For more details, please consult the documentation.
This section is a subset of the complete list of resolved issues. It’s curated to bring attention to the bugs that seem most likely to impact customers.
For a full list, see the issue tracker.
If you encounter any issues with Saxon 12.2, please report them on our issue tracker.
The Saxon 12.1 maintenance release has been published. This is a maintenance release for Java, C#, C/C++, PHP, and Python that fixes a number of issues reported since the first Saxon 12.0 release, in particular it now runs on Java 8.
Saxon 12.1 was released on 21 March 2023. This release has been uploaded to the usual locations on the Saxonica website, GitHub, and Maven, PyPi, and NuGet. SaxonCS 12.1 is built with .NET 6.
For a list of the issues resolved in this release, please visit the issue trackers for SaxonJ and SaxonCS or SaxonC on the Saxon support site.
Download products:
For more details, please consult the documentation.
This section is a subset of the complete list of resolved issues. It’s curated to bring attention to the bugs that seem most likely to impact customers.
For a full list, see the issue tracker.
If you encounter any issues with Saxon 12.1, please report them on our issue tracker.
As part of some infrastructure cleanup, we decided to change how the weblog is managed. It’s now hosted on blog.saxonica.com.
All of the old posts have been copied over and redirects are in place. Along the way, I cleaned up a few broken links.
If anything seems broken, please do let me know!
Happy holidays everyone! Wishing you peace and joy in this festive season!
And toys.
Since we didn't get any releases out before Christmas, we've packaged up a special treat for anyone who wants to play with something new: SaxonC HE 12.0 in Python.
We've built and deployed the Python "wheels" for installing SaxonC HE “11.99” (that's the 12.0 code base, but it's a test release so I didn't want to use up one of the 12.x release numbers). You’ll find the details at https://saxonica.com/saxon-c/1199/.
If you decide to
kick the tyres†,
please do let us know how it goes. There’s still work to do with
installing and packaging, but we think the API is in good shape. (I
did notice that if you call compile_stylesheet()
and the stylesheet
isn’t well formed, the call silently returns None
instead of raising
an error. I’ve
reported that one!)
I’ll probably check my email most days, but I can’t speak for anyone else. Apologies if some of your feedback isn’t properly addressed before the new year.
Once again, wishing you the happiest of holiday seasons!
I have been trying to build SaxonCS for .NET such that I could deliver it on MacOS without warning messages for a long time. It has not been an easy or enjoyable adventure. Here are some breadcrumbs for the next poor soul forced to tread down this path.
You can’t do this with .NET 5. That’s probably less important today than it was when I started. I don’t understand the details, but something has been fixed in .NET 6 that isn’t going to be backported to .NET 5. (There’s a comment to that effect in an issue, but I can’t now locate that issue.)
There are several problems that have to be solved. The application has to be built such that it will run when signed. All of the various pieces have to be (correctly) signed. A DMG must be constructed to distribute the application (maybe I don’t have to do this step, but it’s reasonably what users expect). The DMG has to be signed. And the whole thing has to be notarized by Apple so that it will open without warnings.
A complete, hands off, CI-driven build of a C# application to produce a MacOS DMG file that a user can open and use without any warnings about unsigned code or potentially malicious applications.
Before you begin, there are some things you have to have setup.
You need dotnet 6 (or later, I assume, but we’re planning to ship Saxon 12 with .NET 6 so that’s what I’m using).
You need the nuget command line tool. This is distinct from the nuget subcommand of the dotnet tool. As far as I can tell, only the former can actually install packages.
On a Mac, you need the Mono framework and some other fiddling to make it work. Because that’s the way it is. The details are outlined on the tools page linked above.
You’ll need XCode. I’m using version 14.2. I think you need to install the XCode command line tools and you need to run XCode at least once, it does a bunch of initialization the first time it runs.
You need an Apple developer account and you have to go through the dance necessary to create a developer ID certificate. The certificate and (at least some of) the certificate chain need to be downloaded and installed in your keychain. I don’t remember the exact details, but I seem to recall that it was spelled out reasonably well in the Apple developer documentation.
I decided to use DMG Canvas to build the DMG. In addition to building the DMG, this application does the sign and notarize dance with Apple for me. $20 well spent, I think. I assume these steps can be done manually, but I’m not inspired to try to figure out how just at the moment.
Use the nuget command to install Dotnet.Bundle
:
$ nuget install Dotnet.Bundle
This package constructs the “bundle” of files that MacOS expects
for an application. (That’s the application.app
directory
and its descendants.)
Start with your application. In our case, this complex beast:
using System;
namespace HelloWorld
{
public class HelloWorld
{
public static void Main(string[] arg)
{
Console.WriteLine("Hello, World!");
}
}
}
You will also need a .csproj
file. Here’s one that works
for me:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<PlatformTarget>AnyCPU</PlatformTarget>
<DebugType>pdbonly</DebugType>
<Optimize>true</Optimize>
<OutputType>Exe</OutputType>
<TargetFramework>net6.0</TargetFramework>
<PublishSingleFile>true</PublishSingleFile>
<SelfContained>true</SelfContained>
<PublishReadyToRun>true</PublishReadyToRun>
<RuntimeIdentifier>osx-x64</RuntimeIdentifier>
<UseHardenedRuntime>true</UseHardenedRuntime>
<ImplicitUsings>enable</ImplicitUsings>
<Nullable>enable</Nullable>
<IncludeNativeLibrariesForSelfExtract>true</IncludeNativeLibrariesForSelfExtract>
<IncludeSymbolsInSingleFile>false</IncludeSymbolsInSingleFile>
</PropertyGroup>
<PropertyGroup>
<CFBundleName>HelloWorld</CFBundleName>
<CFBundleDisplayName>HelloWorld</CFBundleDisplayName>
<CFBundleIdentifier>com.saxonica.helloworld</CFBundleIdentifier>
<CFBundleVersion>1.0.0</CFBundleVersion>
<CFBundleShortVersionString>1.0.0</CFBundleShortVersionString>
<CFBundleExecutable>HelloWorld</CFBundleExecutable>
<CFBundleIconFile>HelloWorld.icns</CFBundleIconFile>
<NSPrincipalClass>NSApplication</NSPrincipalClass>
<NSHighResolutionCapable>true</NSHighResolutionCapable>
<NSRequiresAquaSystemAppearance>false</NSRequiresAquaSystemAppearance>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="DotNet.Bundle" Version="0.9.13" />
</ItemGroup>
</Project>
The first property group specifies properties of the build, the second defines how the application will be bundled, and the last item group is necessary to make the bundler part of the build.
Notes:
net6
for the framework and create
a single file, self-contained application.HelloWorld.icns
from a PNG with ImageMagick.Add Dotnet.Bundle
to the project:
$ dotnet add package Dotnet.Bundle
(You only have to do this once.)
Build the application:
$ dotnet msbuild -t:BundleApp -p:RuntimeIdentifier=osx-x64 -p:Configuration=Release
You can run the bundled application to make sure it works:
$ bin/Release/net6.0/osx-x64/publish/HelloWorld.app/Contents/MacOS/HelloWorld
Hello, World!
Next we have to sign the application. But before we can do that, we have
to make an entitlements plist file. I called mine entitlements.plist
:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>com.apple.security.cs.allow-jit</key>
<true/>
<key>com.apple.security.cs.allow-unsigned-executable-memory</key>
<true/>
<key>com.apple.security.cs.disable-library-validation</key>
<true/>
<key>com.apple.security.cs.disable-executable-page-protection</key>
<true/>
</dict>
</plist>
Now we can sign it:
$ codesign --force --options runtime --entitlements ./entitlements.plist --deep \
--sign "Developer ID Application: YOUR DEVELOPER ID GOES HERE" \
--timestamp bin/Release/net6.0/osx-x64/publish/HelloWorld.app
You must use the entitlements option and the timestamp option. (You probably need all the other options too, but those were the ones that I initially overlooked.)
You can run it again to make sure it still works:
$ bin/Release/net6.0/osx-x64/publish/HelloWorld.app/Contents/MacOS/HelloWorld
Hello, World!
(It didn’t for me for the longest time!)
Fire up the DMG Canvas application. (Yes, I know, I said I wanted this to be a hands-off process. I believe DMG Canvas can be automated, but I haven’t tried to figure out exactly how yet.)
The first time you open it up, go to the Preferences dialog and add your Apple ID and a one-time password on the Notarization tab:
This will enable signing and notarizing the DMG later.
On the main screen, add the application to the canvas. On the right hand side, choose the second tab and select “Code Sign and Notarize” in the drop down. You’ll have to specify the certificate you want to use, your Apple ID, and the primary bundle ID. (I have no idea what that means in this context, but you have to put something in there.)
Click the “Build” button in the upper right corner, fill in the details,
Hit Save and wait (nervously, and for quite a while) for the results!
With luck, it all goes smoothly and you get back a signed, notarized DMG file.
There’s obviously more to be done in the DMG: it needs a background image, the
standard symlink to /Applications
should be present, etc. But
I got a working DMG file out of it so, I’m
declaring victory for the moment.
We first published SaxonCS 11.x using .NET 5. Since then, .NET 5 has reached “end of life” and .NET 6 has become the recommended “long term service” release of the .NET framework.
This puts us in a bit of a bind.
On the one hand, we try not to make disruptive changes in a maintenance release if we can avoid it. Consequently, we’re reluctant to suddenly require all of our customers who might be building applications with SaxonCS 11.x to upgrade to .NET 6 just because they want to install a new maintenance release.
On the other hand, it is becoming difficult to support .NET 5 applications in some environments. Ubuntu 22.04, for example, doesn’t ship with the SSL libraries that .NET 5 requires. This makes it difficult, perhaps impossible, to deploy SaxonCS 11.x built with .NET 5 in some environments.
As a compromise, we’ve published a set of SaxonCS 11.4 releases built against .NET 6. In order to distinguish them from their .NET 5 counterparts, we’ve named them “SaxonCS-b6”. The “b6” is both a nod towards their .NET 6 provenance and a way of identifying them as “beta”. There are no code changes in these builds, they should perform exactly as the SaxonCS 11.4 release does, but they have not been tested extensively.
They are identified as “SaxonCS-b6 11.4.1”. You can get the platform-specific release artifacts from our downloads area and the NuGet package has been uploaded and should be available soon.
(Speaking of NuGet, I should also confess that I published the wrong SaxonCS 11.4.0 artifact. The SaxonCS 11.4.0 release on NuGet will only work on 64 bit platforms. I republished the corrected, architecture independent release as SaxonCS 11.4.1 yesterday.)
We’ll have to cross this bridge again if we publish another Saxon 11.x maintenance release. Please let us know what works for you, and what doesn’t.
The very observant among you may have noticed me making a bunch of changes to the SaxonJS issues list this afternoon. We’ve started planning for SaxonJS 3.0 and we’ve made a couple of early passes over the issues list.
Today, I tried to make the actual issues list reflect some of those tentative plans. I’ve added “SaxonJS 3.0” as a milestone to a bunch of issues and I’ve moved some of the priorities around.
Don’t read too much into that at the moment. For one thing, there’s almost certainly too much on the list, for another I expect we’ll do at least one more maintenance release of 2.x before we get to 3.0.
But we have to start somewhere. Feedback welcome.
I haven’t worked with web components very much, though they’ve been on my “must explore more” list for a while. A couple of days ago, I stumbled across Shoelace, “a forward-thinking library of web components.”
“That’d just work in SaxonJS, right?”, I asked myself.
Yep. I updated the helloWorldJS repository that I created a while back to demonstrate it.
The new work is in the shoelace
branch.
There’s not much different, really.
button
element, we use the Shoelace
web-component: <sl-button>Click me</sl-button>
.
match="sl-button"
.That’s pretty much all there is to it. Neat. I must try out some more web components when I have a chance. In principle, the seem like a really good idea.
Saxon-JS 2.2 has been published on Saxonica.com and to the npm registry!
This is a maintenance release that fixes a few bugs. The big one, to my mind, is resolving
the “global object” bug in Node.js. Previous releases of Saxon-JS always
created a global object named “SaxonJS
”. This isn’t best practice on
Node.js and interfered with some platforms like
Electron
and Webpack.
Starting with 2.2, on Node.js, the global object no longer gets created. If you’ve consistently used
const SaxonJS = require('saxon-js');
to load Saxon-JS, you’ll be fine. If you’ve used some other name for the object, make sure that you refer to Saxon-JS exclusively by that name. For example:
const sjs = require('saxon-js');
const six = sjs.XPath.evaluate("3+3");
console.log(`six = ${six}`)
We fixed a few other bugs as detailed in the change history. Thanks to everyone who took the time to report them!
Happy New Year!
As of a few minutes ago (at time of publication!), Saxon-JS 2.0.3 has been published to the npm registry. This release contains no changes in functionality (this is not the release you’ve been waiting for, we’re still working on that one).
The previous version has a published dependency on
axios version
0.19.2 which is, apparently, the subject of a security vulnerability
(or so npm install
asserted this morning).
This tiny release simply updates the dependency to a patched version of axios.
Axios is an HTTP library that is only used by the NodeJS version of Saxon-JS. When Saxon-JS is running in the browser, it uses the browser’s APIs, so this update should have no consequences for the browser version at all.
You may already have seen my helloWorld.Saxon-JS posting. That was about getting Saxon-JS working in your browser. This post is about getting Saxon-JS working in Node.js.
I’m still tinkering with some personal projects and I’ve decided that for one of them, I’m going to experiment with using Node.js. The app is going to do its thing and then eventually I’m going to want to build a web page to show the results.
I’m sure there are ways to do this in Node.js, but this is pretty much the first ever thing I’ve built in node, so I don’t know what they are. What I do know is that I’ve got a wodge of JSON and I want to turn it into a web page.
XSLT to the rescue. And XSLT on the server side this time.
As before, I was able to follow the documentation and get it up and running. But once again, it involved a lot more head scratching (and re-reading the SaxonJS.transform API page) than I would care to admit. This time, I think the main difficulty was my inexperience with node more than anything else.
What I would have liked this time was a simple Node.js project that pulled all the pieces together so that I could build it and see it working, and then begin to hack on it.
So I built one: https://github.com/Saxonica/helloWorldNodeJS.
There’s really nothing to show, it’s about getting it to run locally, but I think the TL;DR is pretty straightforward.
I haven’t actually looked at the server logs to see if anyone else tried using our experimental Maven repository after I posted about it earlier this month. But I have, and it’s worked for me!
I think we’d have to agree that it’s still experimental. After I put up a raw set of files in a directory structure, a couple of folks said I should be running a server to do this. I might do that, but I haven’t had time to try it out yet.
Behind the scenes, I’m also working on build automation. Ultimately, I want these artifacts to be published automatically.
In the meantime, I’ve added the 9.9.1-8 and 10.3 releases of HE (also available on Maven Central), PE, and EE to our Maven repository.
The experimental Maven repository is at https://dev.saxonica.com/maven/.
If you can try it out and let me know if you have trouble (or if you don’t!), I’d appreciate it.
What happened was, last Friday I decided to make my first foray into using Saxon-JS. I have in mind a personal project that would use it for rendering and I wanted to get my feet wet.
I was able to follow the documentation and pretty quickly I had it up and running. But along the way, I stumbled a couple of times. I didn’t read the documentation carefully enough in one case and in another, I introduced a typo into a URI.
What I would have liked was a simple project that pulled all the pieces together, one where I could build it and see it working, and then begin to hack on it.
Since I didn’t find one of those, I built one: https://github.com/Saxonica/helloWorldJS.
On the plus side, this project demonstrates both replacing and appending to web page content with an XSLT transformation, responding to user events, and calling external JavaScript libraries.
On possibly the less plus side, I’ve used Gradle to pull all the pieces together. You might argue that obfuscates things a little bit, if you aren’t familiar with Gradle, but I wanted to put things in the context of an actual project build and that’s what I use for builds these days. PRs for branches that demonstrate Make or Ant or your build tool of choice are welcome. That’s not meant to be the interesting part.
There are three branches.
main
use-script
script
element. It was an experiment I wanted
to try. It avoids a round trip to the server to get the XML document at the cost
of having to extract and parse the document from the HTML.
render-commonmark
src/main/js/start.js
is a bit cleaner in this
branch, too.
All three branches include a button that responds (by running an XSLT template in the stylesheet) when you click it.
I’ve published the simplest version online, if you just want to see it in all it’s dull glory.
A few days ago, when I said that I’d updated the weblog infrastructure, a couple of folks immediately asked “where are the feeds?”
Good question. I wondered that myself.
I hadn’t got around to it at first, but I spent a little time today putting them back where (I think) they were:
If you have trouble, please let me know. “It works for me.”
(The irony that this update won’t turn up in your feed reader is not lost on me.)
Do you have a license for Saxon PE or EE? Do you use Maven? Would a Maven repository for Saxon PE or EE be useful to you? (Saxon HE is already released into Maven Central.)
I’ve sometimes thought it would be useful, and I fielded a customer request for it, so I’ve tried to set it up. It’s a bit experimental at the moment because I’m not entirely certain that I understand all of the metadata files that are expected in a Maven repository.
I’ve only packaged up the Java release of Saxon 10.2 for the moment, but if I can get it usefully configured, I’m happy to try to make it part of the normal release process. We’re thinking of putting some of the older releases up as well to simplify regression testing.
The experimental Maven repository is at https://dev.saxonica.com/maven/.
If you can try it out and let me know if you have trouble (or if you don’t!), I’d appreciate it.
A month to the day since I started working at Saxonica, I’m writing my first weblog posting. I’ll be perfectly honest, it’s mostly to test that the (new) weblog infrastructure is working. (I’m the new guy, so I’m doing a few infrastructure-y things. But I’ve also fixed a couple of bugs! And I have bigger plans!)
We’ve upgraded some of the servers (By “we” I mean mostly O’Neil. Thank you O’Neil!) and I’ve moved the weblog out of Movable Type. It’s now a flat collection of XML files that get published with Saxon. It may be a little rough around the edges at the moment, but I don’t think I accidentally lost anything. (We have decided not to republish the comments from the old weblog.) If you find any broken links or things that don’t look right, please let me know. The sort of markup you get out of weblog tools is, uh, interesting.
Behind the scenes, I’m moving our CI/CD infrastructure forward and I hope to publish an experimental Maven repository for the Saxon EE product “real soon now.”
I’m not exactly sure how I’ll divide up my writings between this weblog and my personal weblog. I’ll try to cross-link where it’s appropriate.