Skip navigation
evlogimenos
Currently Being Moderated

LrXML xsl transform cannot match document node on windows

Jul 22, 2012 11:05 AM

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.

 
Replies
  • Currently Being Moderated
    Jul 22, 2012 6:23 PM   in reply to evlogimenos

    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

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 23, 2012 5:17 AM   in reply to evlogimenos

    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 PMlightroom.exe28940Load ImageC:\Windows\System32\msxml3.dllSUCCESSImage 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

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 23, 2012 9:12 AM   in reply to Matt Dawson

    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

    
     
    |
    Mark as:
  • Currently Being Moderated
    Jul 23, 2012 3:44 PM   in reply to John R. Ellis

    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

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 23, 2012 7:14 PM   in reply to evlogimenos

    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

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 24, 2012 12:27 AM   in reply to evlogimenos
     
    |
    Mark as:
  • Currently Being Moderated
    Jul 24, 2012 4:49 AM   in reply to evlogimenos

    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

     
    |
    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points