Saxon

Legacy ID: #7679745 Legacy Poster: Shankar Arunachalam (shankzz)

Played with the xslt, commenting and uncommenting sections of it to test the flow. Found that there was the following definition which was causing the exception: <xsl:variable name="bound_operation" select="//w11:binding[resolve-QName(@type, current()) = $portType_name]/w11:operation[@name=$operation_name]"/> I removed one slash from the entry and the exception went off. I do not understand the significance of it though!

Legacy ID: #7683883 Legacy Poster: Michael Kay (mhkay)

You haven't supplied the source XML document that triggered the failure, so I can't debug it for you. It looks to me as if the XSLT code is not going to great lengths to do validation on the input. Given the change you describe that makes the error go away, I would guess that your XML input contains a w11:binding element that either has no @type attribute, or whose @type attribute is not a valid QName. Changing the leading "//" to "/" simply means that the w11:binding element is no longer selected, which may prevent the failure, but also probably means that the stylesheet won't produce any very useful output. I don't know why the transformation should work when run on the W3C server and not when you run it yourself. But you haven't supplied any evidence that there is a Saxon problem here: you should raise the problem with the developers of this stylesheet.

Legacy ID: #7684003 Legacy Poster: Shankar Arunachalam (shankzz)

Hi Michael, Thanks for the response! As I had mentioned earlier, my input xml document is the WSDL itself ([http://uncerta.in/tech/service.asmx?wsdl][1]). I wrote my previous response very early today morning or very late yesterday night (sleepy eyes and all that :) ). Since then, I have had a look at it and understood the implication of removing the "/". I would look into the type attribute of the source and also try to get in touch with the dev of the xslt. I do not believe that there is any saxon problem in this. Thanks for your time! [1]: http://uncerta.in/tech/service.asmx?wsdl

Legacy ID: #7684540 Legacy Poster: Michael Kay (mhkay)

Looking at your code more carefully, I see that you are using the .NET version of Saxon. I've run it using Saxon-HE 9.2.0.2 on .NET and reproduced the failure. (Is that the release you are using?) The transformation works without failure when run from the command line, either on Java or .NET. As the error message states, it's having problems when resolve-QName() is called to process the @message attribute in <wsdl:input message="tns:GetGeoDataForLocationSoapIn"/>. This strongly suggests a bug either in Saxon or in the XML parser. I'll have to create a debugging environment in which I can try to work out exactly what is happening. One difference in this scenario from others (such as command line processing) is that when the input is supplied as a .NET XdmNode, xsl:strip-space has no effect. But I can't see any way that space stripping (or not doing it) would cause this error.

Legacy ID: #7691188 Legacy Poster: Michael Kay (mhkay)

It's proving quite difficult to get to the bottom of this. What's happening is that resolve-QName() is being called with an empty sequence as its first argument, and the function is behaving as if it were called with a zero-length string, which it rejects as invalid. Replacing all calls to resolve-QName() by calls to my:resolveQName() solves the problem, where my:resolve-QName is defined like this: <xsl:function name="w11:resolve-QName" as="xs:QName?"> <xsl:param name="s" as="item()?"/> <xsl:param name="e" as="element()"/> <xsl:sequence select="if (empty($s)) then () else resolve-QName($s, $e)"/> </xsl:function> I'm no nearer to working out why this is happening, and in particular why it is only happening when running from the .NET API. I did notice a couple of errors in the stylesheet as a result of my tracing, but they aren't relevant to the problem. There are several cases where resolve-QName() is called specifying the wrong element to resolve against. An example is the call resolve-QName(w11:input/@message, .), which will fail if the namespace prefix used in @message is declared on the w11:input element. I'm also looking into why there are no line numbers in the run-time error message.

Legacy ID: #7692743 Legacy Poster: Michael Kay (mhkay)

I finally got to the bottom of this, and I've logged the bug at https://sourceforge.net/tracker/?func=detail&amp;aid=2870002&amp;group_id=29872&amp;atid=397617. It turns out it can be reproduced on the Java platform if run with the right configuration options. Thanks for reporting it.

Legacy ID: #7692758 Legacy Poster: Shankar Arunachalam (shankzz)

That's great Michael! I have been following your comments here with great interest and it is awesome that you could get to the root cause. I was in the process of setting up a debugging environment for the Saxon codebase to attempt to work in tandem with you, but you have already nailed it :) Thanks for the effort!