(I'm creating this bug issue, because I am choosing to NOT fix this as part of the initial integration of multi-file schema stuff into spin 7).

Properties that contain QNames (any expression, a few others) are not properly resolved. A QName like "foo:bar" the interpretation of "foo" as a prefix must be done using the context of the xml object where that property physically resided.

In our code base, properties are retrieved using getProperty(..) which does not return any information about where the property was found; hence, if the value contains a QName, it can't be resolved properly.

There is a replacement now called findProperty which returns an object containing both the value and a handle on the object which contained the property binding. This allows proper QName resolution if needed, and also enables better diagnostics because we can point at file and line number where the annotation physically was written.

This bug is to convert some calls to getProperty or getPropertyOption into findProperty and findPropertyOption so as to support proper QName resolution.

Note that the expression compiler needs to be fed this information, as that is what deals with qnames embedded in expressions e.g., ./foo:bar/baz[2].