Hi,

I don't know how Altova manages multiple imports of the same namespace. The note that you cited include another part before:

Note: The above is carefully worded so that multiple ing of the same schema document will not constitute a violation of clause 2 of Schema Properties Correct (§3.17.6.1), but applications are allowed, indeed encouraged, to avoid ing the same schema document more than once to forestall the necessity of establishing identity component by component. Given that the schemaLocation [attribute] is only a hint, it is open to applications to ignore all but the first for a given namespace, regardless of the ·actual value· of schemaLocation, but such a strategy risks missing useful information when new schemaLocations are offered.

So I've to check if permitting multiple imports of the same namespace will not produce problems on deciding which components consider to build the complete schema in case of name collisions. In these cases for import/redefine/override an error is raised, but for imports I've to check if this can be a problem. Consider that imported schemas are often edited by others.

Anyway the recommendation is clear in the note so allowing multiple imports of the same namespace will be eventually supported by an option and disabled by default.

Thank you

Hi, thanks for the consideration.

I think name collisions with multiple imports should be handled the same as name collision in includes, or, in the same schema. It is up to the schema authors to avoid them and to know what they are doing.

Locations in <xs:import/> statements are only hints that validators could ignore, this is a big difference with inclusions (also redefine and override). So collisions caused by includes are in fact errors. Collisions of imports can be generated by assembly schemas from various namespaces, and sometimes, reloading the same schema can happen.

The enhancement will be included in the next major release. Probably it will be handled with one or more loader classes. The default strategy will remain the current (process only the first import for each namespace), the others will be based on the absolute URL of schemas. I will include also a URL-based loader that reject imports that generate a collisions (producing only a warning).

With a class-based loader the behavior can be changed by a developer/user using a derived class.