XSL message in a XSLT transform throws a RuntimeError

[higherpixels]

source = Nokogiri::XML(File.read monograph_filename)
xsl = Nokogiri::XSLT(File.read 'ipm.xsl' )
transformed = xsl.transform(source)

The last line throws a runtime error because the xls file contains a message

<xsl:otherwise>
  <xsl:message>Warning:  Class not handled:  <xsl:value-of select="$vDiv"/></xsl:message>
</xsl:otherwise>

So we get the error

RuntimeError: Warning:  Class not handled:  date lrvdt

Is there a way for me to suppress the warning so I don't get a runtime error?

[flavorjones]

@higherpixels - Can you provide a working example of this issue? This would save time in trying to reproduce, as well as saving me the embarassment of admitting I have no idea how XSLT works!

Background for this bug-report policy is here:

http://www.nokogiri.org/tutorials/getting_help.html

Thanks!

[higherpixels]

This should recreate the error

source = Nokogiri::XML(File.read "ipm5547_eng.xml")
xsl = Nokogiri::XSLT(File.read 'ipm.xsl' )
transformed = xsl.transform(source)

http://temp-host.com/download.php?file=nx92xy
http://temp-host.com/download.php?file=cc54gq

[flavorjones]

Excellent, thanks so much! I've reproduced it and am looking into it.

On Thu, Jan 22, 2015 at 9:57 AM, higherpixels notifications@github.com
wrote:

This should recreate the error

source = Nokogiri::XML(File.read "ipm5547_eng.xml")
xsl = Nokogiri::XSLT(File.read 'ipm.xsl' )
transformed = xsl.transform(source)

http://temp-host.com/download.php?file=nx92xy
http://temp-host.com/download.php?file=cc54gq

—
Reply to this email directly or view it on GitHub
#1217 (comment)
.

[flavorjones]

OK, so I've done a bit of research, and it appears as though using xsl:message is expected to raise an error of some sort. My sources:

• https://msdn.microsoft.com/en-us/library/ms256441(v=vs.110).aspx
• http://www.devguru.com/technologies/xslt/8437

The second reference notably mentions "The xsl:message element is primarily used to report errors by displaying a text message".

What is the behavior that you expect in this case?

[mejackreed]

I'm seeing the same issue.

[kmeister2000]

I came across this issue because I was debugging an xsl template and had read a couple of articles that recommended the use of xsl:message to provide helpful feedback in figuring out the order and selection of templates.

To address @flavorjones question in the comment above, based on what I read I would expect the behavior to be displaying the message content on the console or returned by the XSLT.transform method somehow.

Reference: "The xsl:message element is optional. Processors are not required to support it. However most do, and usually they do so by printing messages on the console."
http://www.ibm.com/developerworks/library/x-tipxslmsg/

[frivoal]

I'm affected by this as well, and it would be very useful to have the choice of what to do, and here are two possible ways the API could be changed to support it:

xslt = Nokogiri::XSLT::Stylesheet.parse_stylesheet_doc xslt_file
output = xslt.transform(input) do |message|
  puts message
  #raise an exception if you want, but if you don't we just keep processing
end

or

xslt = Nokogiri::XSLT::Stylesheet.parse_stylesheet_doc xslt_file
xslt.handle_messages  do |message|
  puts message
  #raise an exception if you want, but if you don't we just keep processing
end
output = xslt.transform(input)

Alternatively, instead of raising exceptions directly, the block could take an second parameter

xslt = Nokogiri::XSLT::Stylesheet.parse_stylesheet_doc xslt_file
xslt.handle_messages  do |message, transform|
  puts message
  transform.continue
  # or
  # transform.abort
end
output = xslt.transform(input)

[flavorjones]

@frivoal What would you think about adding the error to the Document#errors array, if the xsl:message does not declare terminate="yes"?

[frivoal]

@flavorjones Just to be clear on what you're proposing:

• it does not declare terminate="yes" you would just continue processing and store the error in Document#errors
• it does declare terminate="yes", abort imediately (and store the message in Document#errors ? and print the message on stderr?)

Yes, this would work. Transformations that are supposed to continue would continue, and those that are supposed to stop would stop.

I think it would probably be better to put the messages in something like document#messages (at least when terminate="yes" is not declared) since these are not actually errors, and may not even be warnings at all, but that's less important. This would be a question of API intuitiveness, not of capabilities or correctness.

Another small limitation of that design would be when the non-terminating messages are meant to give progress reports in a long running task, just storing them in Document#errors and letting the caller read them at the end defeats the purpose. This is secondary, since the processing would still occur normally, but the messages would be less useful than could be.

That said, your proposal is actually compatible with mine: the default message handler would do what you said, and you could let users supply their won, using something like a handle_message method on XSLT::Stylesheet, which would take a block, and pass it the message and terminate as a boolean, and allowing it to signal somehow if it wants processing to continue or stop. I guess that would be ideal, getting the best of both worlds.

[flavorjones]

A brief investigation of libxlst and its xsltMessage function leads me to believe that it's not currently possible to filter xsl:message messages differently from other parse errors and warnings.

@nwellnhof if you have a moment, please let me know if I'm missing something.

[flavorjones]

And if that's the case, then I can update Nokogiri's code to only raise an exception if the parsing failed (i.e., xsltApplyStylesheet returning NULL), and otherwise we can stash all of the warnings and messages in an accessor.

[nwellnhof]

A brief investigation of libxlst and its xsltMessage function leads me to believe that it's not currently possible to filter xsl:message messages differently from other parse errors and warnings.

That's correct. libxslt's error handling is extremely limited. It never implemented what libxml2 calls "structured" error handling.

[flavorjones]

Thank you! I'll schedule some time to make Nokogiri's behavior a bit more robust, then.