This is done with the import element, a part of the standard XMLSchema definition. The import element should be used with 2 attributes: namespace and schemaLocation. The namespace will be used by the XML to link elements up with their unambiguous definition. For example, distinguishing between <myschema:total value="150" /> and <yourschema:total computedValue="150000" />. schemaLocation points to the authoritative source for the XSD.
See the following XSD snippet.
There is a file called atd.xsd that references atd-common.xsd. atd-common.xsd provides common type definitions and is referred to using the namespace "http://www.all-travel-data.com/atd-common". Shorthand, XML elements will refer to atd-common as "cmn" in accordance with the attribute in <xs:schema>
schemaLocation is pointing to a file on a web server (it's really there). With Structured Schema Designer, it's important that schemaLocation be set. Otherwise you'll get this error.
Sometimes in development, it's handy to use copies of files. However, this practice often causes problems with tooling because schemaLocation is a URI and not a fully-qualified file path like C:/schemas/atd-common.xsd. Structured Schema Designer can ease development because once the structured schema is generated, it can be used without referring to the XSD.
In most cases, your XML data will take definitions from multiple schemas. This is so that solutions can be composed instead of re-created new definitions with each new XML initiative. If you're using Pervasive Data Integrator, or other tools, be aware that you'll need to accurately set the schemaLocation attribute on any import statements.
This post is replicated from http://my.opera.com/walkerca/blog/schemalocation.