XML Transformations/Stylesheets

[mje]

Are any of you familiar if I can apply xml transformations or stylesheets using LabVIEW's built in capabilities? I'm thinking it can't be done...

Have any of you used the xerces/xalan binaries before? They seem like they ought to be able to do the trick. Since I'm platform locked to Windows, .NET ought to work as well. Or maybe other recommendations?

[candidus]

I also wonder why LV installs xalan but doesn't provide an API to it...

There's a project called LabXML (labxml.sourceforge.net, LGPL license). It is based on the opensource library libxml2 and supports XSL transformation. I usually use it when I have to work with stylesheets. Besides .NET, on Windows the MSXML 4.0 COM library is also an option.

[Mr Mike]

I've done it before using .NET methods. I don't remember where I did it, so I can't give you a copy. It's fairly easy to do if you just port the .NET example to LabVIEW.

[mje]

I wasn't aware LabVIEW actually had xalan...

Anyways .NET looks easy as pie. Seems the winner to me.

Thanks both of you.

[crelf]

Are any of you familiar if I can apply xml transformations or stylesheets using LabVIEW's built in capabilities? I'm thinking it can't be done...

I guess it depends on what you want to do. We use custom xsl stylesheets a lot with ATML reports, and occasionally have to nip into the data to make mods (which, as suggested by others, we do with .Net - we've built up a reuse library of such functions that wrap the .Net stuff, and is compatible with the LabVIEW vi.lib functions).

[ASTDan]

Have you looked at JKI's Easy XML toolkit

http://jki.net/easyxml

[mje]

Indeed, JKI's tool is useful for getting XML data in/out of LabVIEW. We don't use it, but do have a very similar re-use library I had developed before Easy XML came to be (or at least before we were aware of it). However I'm not looking to get data in and out of LabVIEW, only to manipulate XML data which already exists.

I have code which generates an XML export of my LabVIEW data model, and now I want to be able to pull in arbitrary stylesheets to apply a transformation to that XML to generate different reports in html, docx, etc. The idea here is I don't want to write arbitrary LabVIEW code for each supported report style. I don't even want the application to be aware of the details of the potentially unbounded number of reports that might be able to be generated. I'll have a single branch of LabVIEW code that creates XML according to a well defined schema, and report generation gets offloaded entirely from LabVIEW: once the XML is created, the application will just grab some stylesheet the user has picked (XSLT), apply the transformation to the XML, and save the output to disk.

[ASTDan]

I have never tried this, but you specify a url to a stylesheet in the Easy Write XML File

Edited January 31, 2012 by ASTDan

[mje]

Interesting, thanks for pointing that out, I'll have to look into it. I expect supplying a stylesheet URL might simply insert a processing instruction into the prolog of the document?

<?xml-stylesheet type="text/xsl" href="path.xsl"?>

[/CODE]

I'll have to download Easy XML to check it out I suppose.

[jgcode]

Interesting, thanks for pointing that out, I'll have to look into it. I expect supplying a stylesheet URL might simply insert a processing instruction into the prolog of the document?

<?xml-stylesheet type="text/xsl" href="path.xsl"?>

[/CODE]

I'll have to download Easy XML to check it out I suppose.

That would be my guess - that it just inserts the XML declaration.

mje - if you can, in the future, please update this thread with code that you implement - that would be really sweet.

[mje]

I still haven't looked into the JKI solution, but here's what I got for a .NET wrapper:

XslTransform LV10.zip

There's a class in there with 4 methods.

Apply Xslt.vi: This is a high level static VI. You don't need to know anything about classes or refnums to use it. Just point it to an XML document, an XSLT document, and give it a local file path to save the output to and go.

Create.vi, Transform.vi, Destroy.vi: This is the lower level set of VIs that encompass the traditional create, reuse, destroy paradigm. If you plan on applying the same transform to multiple source documents, this is what you want to use since you only need to compile the XSL once using this method. Transform.vi is also thread safe, so you can have multiple processes spinning each sharing the same compiled xslt.

That said, I'm not a fan of the .NET 2.0 XML implementation at all. This was a quick wrapper that was easy to implement, but produces rather ugly output compared to more modern tools. I continue to look for other libraries to use, currently examining Saxon. I really like the output the Altova tools I use produces, I have no idea what they use under the hood.

The code I posted above is a VERY thin wrapper around .NET code. I make no claim to it, anyone is free to do with it as they see fit.

-m