You seem to be on the right track. I’ll make a few points here that might help.
- Within an instance document, you use XML namespaces to identify the namespace that an element or attribute is in.
- Within a schema document, you declare elements and attributes that will appear in instances. What namespace are they declared to be in? This is what targetNamespace is for.
- The schema document location and the namespace are not the same thing. It is quite common to have multiple .xsd documents with the same targetNamespace. (They may or may not include each other, but typically will include each other.)
- Instance documents do not always have an xsi:schemaLocation element to tell parsers where to locate the schemas. Various methods may be used to tell a parser where to locate relevant schema documents. An XSD may be located on local disk or at some web address and this should not affect the namespace of the elements in it.
- xsi:schemaLocation is a hint. Parsers may locate the schema for the given namespace elsewhere, which implies that they must be able to know what namespace a schema is for.
- Tools, such as databinding tools, will precompile schemas and produce code that recognizes valid documents. These must be able to know the namespaces of the declared elements.
I think what you were assuming is that the instance document could specify the namespace of the elements and attributes declared in some schema document, using xsi:schemaLocation. That doesn’t work. For one thing, the parser may locate other schema documents than those listed, and it needs to know what namespace they are for. For another, it would make reasoning about schemas difficult or impossible: you wouldn’t be able to look at a schema and know the namespaces that everything belonged in because that decision would be postponed until an instance was written.