LrXML xsl transform cannot match document node on windows

[evlogimenos]

On windows the xsl library used has a bug which is preventing it from matching the document node (the parent of the root element of the document).

I reduced this to a test case:

xml data:

<first>

  <second />

</first>

xsl stylesheet:

<xsl:stylesheet version='1.0' xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

  <xsl:output method='text'/>

  <xsl:template match='/'>ROOT<xsl:apply-templates/></xsl:template>

  <xsl:template match='first'>FIRST<xsl:apply-templates/></xsl:template>

  <xsl:template match='second'>SECOND<xsl:apply-templates/></xsl:template>

</xsl:stylesheet>

The output should be ROOTFIRSTSECOND and this is the observed output if this stylesheet is processed by msxsl or xsltproc. The problem is, when this is processed by LrXML on windows the output is FIRSTSECOND.

Granted I am not an xsl expert but to the best of my knowledge this looks like a bug. Any chance this can be fixed?

Cheers.

[DawMatt]

Hi,

I haven't messed around with XSLT in a little while so can't verify whether your match criteria for the root node is the correct way to select that node. I'm sure there will be an alternate way to select it so you can probably work around this issue.

My understanding is that Lightroom uses MsXML on Windows to perform the transformation. This raises a few challenges for anyone using XSLT functionality. Particularly that the MsXML version available might differ from machine to machine and between Lightroom versions. It also means that some other engine is being used on Mac so testing on both platforms is highly recommended.

To ensure Lightroom transforms your XML as expected I'd suggest testing with MsXML, preferably the oldest version on your system (e.g. MsXML 3) to verify that your stylesheet should work when called by Lightroom regardless of version or system configuration. You also will really need to test on a Mac if you are planning to support that platform with your plugin.

As to whether this issue can be fixed, Microsoft might already have done so but if that version of MsXML isn't what the system asks to process Lightroom's XML requests then you still have to code for the older behaviour. You might be able to configure the system to present the newer version ot MsXML to Lightroom but I suspect the configuration steps required would be beyond the average user of a Lightroom plugin. So its safest to assume you will have to live with this limitation and work around it..

Matt

[evlogimenos]

As I mentioned in the original post I used msxml.exe and tested this transformation from the command line. I verified this works as expected (produces ROOTFIRSTSECOND). This means that Lightroom does not use MsXML on Windows or at least not the version the Microsoft executable loads. I tried finding which xslt library Lightroom uses but I was unsuccessful.

[DawMatt]

As I mentioned earlier, it is recommended you use the oldest version of MsXML available which usually means MsXML 3. The exe you linked to (which incidentally is not msxml.exe, but rather the msxsl you mentioned in your original post) explicitly states that it uses MsXML 4.

Using a copy of Process Monitor I was able to trace the exact MsXML DLL Lightroom used when executing a plugin using LrXML:

9:36:51.4555689 PM

lightroom.exe

28940

Load Image

C:\Windows\System32\msxml3.dll

SUCCESS

Image Base: 0x7fef7660000, Image Size: 0x1d4000

This confirms Lightroom 4.1 is using MsXML 3 on my system. So testing with msxsl.exe should be close but there is no guarantee that MsXML 3 and MsXML 4 will behave the same when executing your XSL.

Information about the various MsXML versions available can be found here. On my Win x64 system Lightroom is using MsXML 3.0 SP11 but a later build number than mentioned on the MS web page. I'm not clear about which XSL features are added by each MsXML version.

Matt

[johnrellis]

You can find which version of DLLs are loaded by LR or any other program using Microsoft's free "Process Explorer".   My LR 4.1 loads these libraries:

c:\windows\system32\msxml6.dll

c:\windows\system32\msxml6r.dll

[DawMatt]

Thanks John.  I normally use "Process Explorer" as well, but was trying "Process Monitor" to see if I could isolate while DLL was being loaded at the time of the LrXml call. In case different parts of the product use different DLL versions.

John's results seem to support the idea that XML/XSLT parser versions being used may vary. Best to test with older versions of MsXML, where possible, to ensure maximum compatibility of your XSLT scripts being used with LrXml.

Matt

[evlogimenos]

I used process explorer and found that in my case Lightroom uses msxml3.dll. I also ran msxml.exe -u 3.0 which selects the same dll for processing and verified that msxml.exe gives different results that Lightroom.

Here's the code I am running. In Info.lua:

  LrExportMenuItems = {

    {

      title = 'Test XSLT',

      file = 'TestXSLT.lua'

    }

  },

and in TestXSLT.lua:

local logger = import('LrLogger')()

logger:enable('logfile')

local LrXml = import('LrXml')

local utils = require('utils')

local xml_data = [[

<?xml version='1.0' encoding='UTF-8'?>

<first>

  <second />

</first>

]]

local xslt_data = [[

<xsl:stylesheet version='1.0' xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

  <xsl:output method='text'/>

  <xsl:template match='/'>ROOT<xsl:apply-templates/></xsl:template>

  <xsl:template match='first'>FIRST<xsl:apply-templates/></xsl:template>

  <xsl:template match='second'>SECOND<xsl:apply-templates/></xsl:template>

</xsl:stylesheet>

]]

logger:debug('Parsing xml: ' .. xml_data)

local xml = LrXml.parseXml(xml_data)

logger:debug('Applying xslt: ' .. xslt_data)

local res = xml:transform(xslt_data)

logger:debug('Result: ' .. res)

Can you please try and verify that it is broken for you as well?

Thank you.

Fixed code formatting. disht

[DawMatt]

I tested this. Had to remove the "local utils" line from the sample code, add a file name for the logger creation line, and reconstruct a valid Info.lua but otherwise the sample code was OK.

Result on this system was as you expected. "Result: FIRSTSECOND".

Also tried the same XSLT and sample XML in a copy of Stylus Studio 2011 that I happen to have here. With all the available XSLT processors (MsXML, Saxon, Java, .Net) it has available the result included the ROOT text though the whitespace included varied between XSLT processors.

I'm unsure why LrXml's result is different from the standalone processors. Will see if I can dig up more info, but regardless of what we find I think you need to work out a different way to select or match the root node. Either that or wait for this behaviour to be changed and only support that Lightroom release (and beyond) with your plugin.

Matt

[evlogimenos]

Thanks for testing this Matt. Do you know if there is anything else I must do for Adobe to get this bug report? Are these forums monitored by Adobe employees and the bug will be acknowledged?

Cheers.

[areohbee]

Post bug report here: http://feedback.photoshop.com/photoshop_family/topics/new

[evlogimenos]

Posted bug report here.

[DawMatt]

Checked out the bug report, and noticed that the sample code is missing the XML and XSLT content. I'm assuming this was stripped out by the website when you posted it but you might want to see if you can re-add it somehow.

Matt

[evlogimenos]

Thanks Matt. I fixed it now in a reply since I can't edit the top post.