How to find out XSD file dependencies

Question

I would like to store all XSD files which are needed to parse a particular XSD file. This answer says that we should look for xs:include and xs:import attributes.

But what about namespaces used inside elements? Often root elements (schema declarations) have multiple namespace declarations. If we encounter those in XSD files, shouldn't we include the XSDs for these namespaces as well?

For example, in this XSD file, shouldn't we need to include XSDs that define urn:oma:xml:xdm:extensions and urn:ietf:params:xml:ns:resource-lists and http://www.w3.org/2001/XMLSchema namespaces?

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
    targetNamespace="urn:3gpp:ns:mcpttGroupInfo:1.0"
    xmlns:mcpttgi="urn:3gpp:ns:mcpttGroupInfo:1.0"
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    xmlns:oxe="urn:oma:xml:xdm:extensions"
    xmlns:rl="urn:ietf:params:xml:ns:resource-lists"
    elementFormDefault="qualified" attributeFormDefault="unqualified">

    <xs:import namespace="urn:oma:xml:xdm:extensions"/>
    <xs:import namespace="urn:ietf:params:xml:ns:resource-lists"/>

    <!-- XSD element and type definitions -->

</xs:schema>

Answer 1

http://www.w3.org/2001/XMLSchema

is a special namespace for defining schema elements which is automatically understood and by convention (although it's not necessary) uses the 'xs' alias.

Your line

xmlns:xs="http://www.w3.org/2001/XMLSchema"

simply defines the default namespace alias for schema elements.

To include the schemas for urn:oma:xml:xdm:extensions and urn:ietf:params:xml:ns:resource-lists you need to supply a schemaLocation attribute, e.g.

<xs:import namespace="urn:oma:xml:xdm:extensions" 
           schemaLocation="http://yourSchemaLocation/yourSchema.xsd"/>

N.B. the schemaLocation can be relative, which is probably more appropriate and certainly more convenient in my experience for your own schemas. So maybe

<xs:import namespace="urn:oma:xml:xdm:extensions" 
           schemaLocation="./yourSupportingSchemaLocation/yourSchema.xsd"/>

would be a better example.

Answer 2

If we encounter those in XSD files, shouldn't we include the XSDs for these namespaces as well?

If in an XSD schema document we encounter a namespace declaration for a namespace N, one of the following will be the case:

1. It's the XSD namespace and the prefix declared used on elements in the schema.
2. It's the target namespace of the current schema document and the prefix declared is used in references to types, elements, attributes, etc. in the target namespace.
3. It's not the target namespace and is used in references to elements, types, attributes, etc.
4. It's not used in references to (the schema declarations of) elements, types, attributes, etc., but it is the namespace of some element or attribute used in the schema document itself (e.g. inside an xsd:annotation element, or as a foreign-namespace attribute on an XSD element).
5. It's not used in the schema document at all.

If we are seeking to collect a set of schema documents sufficient for validating the elements, attributes, and types defined in the current schema document (or, more or less equivalently, the set of schema documents referred to directly or indirectly, explicitly or implicitly, from the current schema document), then:

1. Case 1 is irrelevant: the schema for the XSD namespace is built in to every conforming XSD validator and need not be collected.
2. Case 2 requires that we collect the schema document we are currently reading. (Presumably we already knew that, or else why were we reading it in the first place?)
3. In case 3, either there is an xsd:import for the namespace, in which case it will be taken care of when we process xsd:import elements, or else there is no such import, in which case the current schema document is non-conforming and will raise an error when a conforming schema processors tries to construct a schema from it.
4. In case 4, the namespace is used in the current schema document (e.g. in an HTML passage contained in the xsd:documentation element); we will need a schema document for that namespace if we want to validate the relevant elements or attributes in the current schema document. But there is no indication that the namespace in question can or will be used in documents to be validated against this schema. The only useful indication that it could be used in those documents would be an xsd:import element.
5. In case 5, the namespace declaration is cruft and serves no discernible purpose. (It may be part of a schema document template used in an organization because the namespace in question is often used in the organization's schema documents -- my schema documents usually declare a prefix for the XHTML namespace -- but not used in this particular schema document for whatever reason.) No schema documents for this namespace need to be collected.

In the sample document you give, there are four namespace declarations. One falls into case 1:

xmlns:xs="http://www.w3.org/2001/XMLSchema"

One falls into case 2:

xmlns:mcpttgi="urn:3gpp:ns:mcpttGroupInfo:1.0"

Two fall into case 3 (or possibly case 5), and for these there are also xsd:import instructions:

xmlns:oxe="urn:oma:xml:xdm:extensions"
xmlns:rl="urn:ietf:params:xml:ns:resource-lists"

If we drove our collection policy by namespace declarations instead of xsd:import and xsd:include instructions, the difference here would be that we (a) add the schema for XSD schema documents to our collection, and (b) possibly search for other available schema documents for the target namespace of the current schema document. (In some cases, that may be desirable; in others, we have different schemas for the same namespace and collecting all of them will be counterproductive because it will produce a redundant and possibly self-contradictory set of declarations.)

Answer 3

All in all, when defining XML schemas, include tags must have location attributes. Otherwise the schema would not be valid. Although XSD files used by import and include statements may be missing and this may trigger validator to proceed with lax validation, they should be treated as dependencies because of the intention to use them in XSD schema.

Since XSD schemas are instance documents as well, they also have a dependency to their schema document. But for this particular case they are in "http://www.w3.org/2001/XMLSchema" (the XML Schema Namespace) namespace, which is hard-coded into XML Validator. So there is no need to provide it.

For "other" instance documents (and this was not part of my question, just mentioning for completeness) created from custom schemas, schema location is not mandatory, although it can be defined explicitly. If it is not defined, XML validator can be instructed to use some schema programmatically - and which file gets chosen at the end depends on implementation.

But it definitely must find some schema to validate instance document against - if there is a namespace declaration to begin with. If this schema has some includes and imports, these files must be available as well, and they must be located at a location specified in location attribute.