Support for imports with schemaLocation values which are not URIs

[TWolverson]

I have a set of schemas with imports, where the schemaLocation attribute has a value which is not a URI. This is permitted by the XML Schema specification which says (regarding xs:import)`:

If present, the schemaLocation attribute is understood in a way which parallels the interpretation of xsi:schemaLocation in (1). Specifically, it provides a hint from the author to a processor regarding the location of a schema document that the author warrants supplies the required components for the namespace identified by the namespace attribute.

My schemas use the schemaLocation attribute to reference a .net typename, as they are BizTalk schemas, and this is permitted by the standard as the typename has meaning to the BizTalk compilation process. When I run the XSD Documenter against these schemas, I get the following error:

SHFB: Error BE0029: Unexpected error while executing plug-in 'XML Schema Documenter': XsdDocumentation.XsdDocumentationException: There was an error constructing the schema set. ---> XsdDocumentation.XsdDocumentationException: There was an error reading the schema file 'path-on-system\example-of-.net-typename'. ---> System.IO.FileNotFoundException: Could not find file 'path-on-system\example-of-.net-typename'.

* reported path has been anonymised

The XSD documenter appears to interpret the schemaLocation attribute as a URI in all cases. This is not necessarily correct for all possible permutations of XML schemas according to the standard. However as this is a hint I accept that a method would have to be devised to interpret that 'hint' correctly and that may be too difficult to generalise.

[terrajobst]

Let me double check, but it's possible that this is a limitation of the underlying .NET XmlSchemaSet.

Could you share a repro? That would help tremendously. Thanks!

[TWolverson]

I was leaning toward that conclusion too having read the source for XmlSchemaSet - and to be fair to them, how could they possibly support some arbitrary referencing scheme for schemas known only to the client?

Still, for the specific job of generating documentation, I wouldn't immediately assume that one has to be able to comprehend all imports for all schemas, so it'd be nice if this wasn't a blocker.

I'll try and produce a repro for this one when I have time and am in front of the code that causes the problem.