Searching a toolkit that can transform XML files using XSL stylesheets

questions
1

I'm creating XML files which needs to be validated to make sure they are really valid.

The validation needs to be done in 2 steps:

  1. Validation using a XSD file.
    I've seen that EasyXML can do this. So maybe an option for me.

  2. Doing a transformation using a XSL/XSLT stylesheet file.
    I've done some research and found that the Microsoft XMLReader .net class does allow this but only for XSLT version 1.0 files. My XSLT file is version 2.0 so this class can't be used.
    I've also came across the SaxonC toolkit which seems to do the job but it also seems to be rather complicated.
    Just as a note: My XSLT file is about 1.7 MB large.

Does anyone know any tools which allow these validations (especially the transformation)?
I'm not searching for an online service. I want to do the validation offline.

Thanks for any advices.

Jens

2

Maybe have a look at XFiles from Capesoft?

3

No, it wont do that.

4

Have a search on GitHub for XML XSLT library, I had a quick look earlier today and found a c library that might have the potential to do what you want?

There are lots of similar tools on GitHub it might be worth a look?

5

I see very limited set of the libraries around supporting xslt 2.0 or 3.0. Saxon has a console utility so the transformations could be done via Clarion RUN().

6

Another way is to downgrade your xslt to 1.0 and use EasyXML :slight_smile:

7

Never used it, but they have a free trial RaptorXML Server | Altova

8

Well since you appear to be blazing a new trail, why not ask Claude…

I want to use an external library that supports XSLT 2+ in a
Clarion for Windows application:


Sketching command-line and DLL examples for Clarion calls.
Yes, that's the pragmatic route, and Saxon is the main choice. There are four ways to wire an external engine into Clarion, from simplest to most integrated.

1. Saxon via the command line (easiest to start with)
Saxon-HE is free and open source (MPL) and supports XSLT 2.0 (and 3.0, which is backward-compatible). You launch it as a process from Clarion:

clarion
Cmd   CSTRING(1024)
  CODE
  Cmd = 'java -jar "C:\Saxon\saxon-he-12.jar" -s:in.xml -xsl:style.xsl -o:out.xml'
  RUN(Cmd, 1)                ! 1 = wait until it finishes
  IF ERRORCODE() THEN MESSAGE(ERROR()).
The downside is JVM start-up cost on every call, plus you have to capture errors from stderr or a log file. That's fine for batch jobs but poor for lots of small transforms.

2. Saxon-C as a DLL (best performance, no Java needed)
Saxonica's Saxon-C ships as a native shared library, so there's no JVM install. Its API is C++ and class-based, which is awkward to call directly from Clarion. The usual fix is a small C/C++ wrapper DLL that exposes flat functions, which Clarion can prototype easily:

clarion
  MAP
    MODULE('xsltwrap')
      XsltTransform(*CSTRING xml, *CSTRING xsl, *CSTRING out), LONG, C, RAW, NAME('xslt_transform'), DLL(1)
      XsltLastError(), *CSTRING, C, RAW, NAME('xslt_last_error'), DLL(1)
    END
  END
The wrapper keeps the processor alive between calls, caches compiled stylesheets, and passes parameters. This is the best option if XSLT is a core feature of your application. The Saxon-C API has changed between releases, so check the current docs for the version you pick.

3. Saxon for .NET exposed through COM
You write a small .NET class library that wraps Saxon-HE (available on NuGet), mark it COM-visible, and register it. Clarion then drives it via OLE/COM automation. This works well on Windows and gives you object-style calls (set stylesheet, set parameters, transform string to string), but you take on COM registration and deployment.

4. Commercial engines
Altova RaptorXML and a few others offer COM or command-line interfaces and support XSLT 2.0/3.0. These make sense if you already have licences or need vendor support.

Avoid MSXML and libxslt, since both are XSLT 1.0 only.

My recommendation
Start with option 1 to prove your stylesheets work and get something running quickly. If performance or deployment matters, move to option 2 behind the same Clarion procedure signature, so the rest of your code doesn't change.

A few questions would sharpen this: Which Clarion version are you on? Do you need to transform files or in-memory strings? And is the app distributed to customers or internal-only? Distribution matters because option 1 requires a Java runtime on every machine. I can draft the Clarion wrapper class or the C wrapper for Saxon-C if you'd like.
9

I was a few days offline and I'm now back.

Thanks for all suggestions.

I will look at EasyXML.
But I think the Saxon route is the best way for the transformation using the XSLT stylesheet.

Jens