Saxon

Note also (and see also bug #2962) there is no method in the s9api SchemaManager that allows the schema for a "built-in" namespace to be loaded.

Perhaps there shouldn't be - it should happen automatically when the namespace is referenced. But the problem then is that things like XPathyCompiler.importSchemaNamespace() explicltly say that the method does not cause the schema to be loaded.

In fact the issued JAR file contains xpath-functions.xsd which xs:include's json.xsd and analyze-string.xsd. The class FnNamespaceSchema appears to be redundant, but does no harm.

I've trying (on the 9.8 branch) to run the JUnit tests in FnSchemaTests after changing them to use

config.addSchemaForBuiltInNamespace(NamespaceConstant.FN);

Not working. It has trouble finding the component schema documents analyze-string.xsd and json.xsd. Tried building a composite SCM for the target namespace (xpath-functions.scm) and loading that instead. This works - though the JUnit test testSchemaInvalid is currently failing.

The reason the unit test testSchemaInvalid() was not working is that the test instance is not actually invalid against the W3C-published schema, which allows mixed content for the fn:analyze-string element. See W3C bug 29976:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29976

The test was previously working because the "born binary" schema created in FnNamespaceSchema sets the outermost complex type to have variety ELEMENT_ONLY rather than MIXED, which is probably correct but disagrees with the W3C schema.

I have changed the unit test to use an instance that isn't sensitive to this problem.

W3C decided to leave the schema as is, that is with the type definition for analyze-string-result specifying mixed="true".