XPath: The variable/parameter: $b:v cannot be resolved here, but it may be defined in an external module.

[vnesterovsky]

Here is modeled test case:

<e xmlns:a="urn:a" xmlns:b="urn:a">

  <xsl:variable name="a:v" as="xs:integer" select="1"/>

  <xsl:sequence select="$b:v"/>
</e>

In real test case I have xsl:param in one file, and use in the other.
Though namespaces are equal, prefixes are different.

Note that similar problem happens with functions defined in different files provided different prefixes are used.

[pgfearo]

I'm afraid that your test case highlights some laziness in the current solution - there is no namespace-lookup for QNames for referenced variables, functions etc.

In fact, the current solution does not track the prefix-namespace binding as it descends down thought the XML tree. It would be quite a bit of work to fix this so I'll have to leave this issue open for the time being but mark it as deferred.

[vnesterovsky]

In my environment, stylesheets for good or for bad use following technique to declare this prefix, and to declare other APIs prefixes:

xmlns:t="urn for this api"
xmlns:x="urn for API x"
xmlns:y="urn for API y"

This technique kills plugin's name resolution.

How hard would it be to fix this? Isn't it just a kind of preprocessing of xs:QName value into a string e.g. in format 'Q{namespace}name'?

[pgfearo]

It's not that hard to fix in terms of complexity, it's just that there are a lot of QNames that are checked so there will be many code changes so it will take some time.

The first part is to change the XML 'parser' so that the current namespace-prefix binding for every node in the XML tree is available. I need to try to do this in a way that minimises the impact on performance/cpu-usage for large files.

Given that all xmlns prefixes are tracked already, it may be that the impact is barely noticeable. I will start looking into this but I'm not sure at this stage how long it will take.

[pgfearo]

I'm still pondering the solution for this. I think the most pragmatic solution here would be: 'if unable to resolve a function reference using prefix and local-name - fallback to attempting to resolve the function reference by local-name only'.

[vnesterovsky]

In my code base in some cases it might find definition. Wrong one.

So, it is silent, worst, kind of error.