W3C home > Mailing lists > Public > xmlschema-dev@w3.org > January 2002

Re: Import/Include/Redefine

From: Jeni Tennison <jeni@jenitennison.com>
Date: Sat, 12 Jan 2002 12:55:30 +0000
Message-ID: <91447481514.20020112125530@jenitennison.com>
To: Niko Suave <niko@alum.mit.edu>
CC: xmlschema-dev@w3.org
Hi Niko,

> 1. Includes referencing each other: can an included document refer
> to things in the including document, or in other included documents?
> I assume the answer is yes, because including should be equivalent
> to cutting and pasting the document into that point in the schema.

The answer is yes (though it's not *exactly* the same as cutting and
pasting - it's a namespace-aware operation).

The relevant description is in Section 4.2.1 of the XML Schema
Structures Rec (http://www.w3.org/TR/xmlschema-1/#compound-schema). In
the third paragraph of that section, it says:

 "The ·XML Schema· corresponding to <schema> contains not only the
  components corresponding to its definition and declaration
  [children], but also all the components of all the ·XML Schemas·
  corresponding to any <include>d schema documents."

Any references between structures in XML Schema are done between
*schema components* rather than XML elements (if you see what I mean),
so the fact that the resulting schema contains these schema components
means that they can refer to each other, across document boundaries,
without any problems.

> 2. Imports referencing each other: can an imported document refer to
> things in the importer? The example is the same as above, only with
> schema 1 importing schema 2 and the appropriate targetNamespace
> transformations.

This is a little more tricky, but I think that the answer is yes.
Right near the bottom of Section 4.2.3 of the XML Schema Structures
Rec (http://www.w3.org/TR/xmlschema-1/#composition-schemaImport),
there's a paragraph that says:

 "The ·schema components· (that is {type definitions}, {attribute
  declarations}, {element declarations}, {attribute group
  definitions}, {model group definitions}, {notation declarations}) of
  a schema corresponding to a <schema> element information item with
  one or more <import> element information items must include not only
  definitions or declarations corresponding to the appropriate members
  of its [children], but also, for each of those <import> element
  information items for which clause 2 above is satisfied, a set of
  ·schema components· identical to all the ·schema components· of I."

The 'clause 2' that's referred to is a clause that tests whether the
schema validator actually retrieves a schema from the xs:import, which
it might not do if, for example, you don't give a schemaLocation and
the namespace doesn't point to a schema or some resource from which
the validator can gain a pointer to the schema.

So the imported schema components are available in just the same way
as the embedded schema components, and they can reference each other
as much as you want.

(As a matter of design, if the imported schema had references to
components from another namespace, I think I'd include an xs:import,
preferably with a schemaLocation, anyway.)

> 3. Imports and xsi:namespaceLocation. If schema 1 imports schema 2
> for namespace XXX, but then the document being validated has an
> xsi:namespaceLocation="XXX schema-3.xsd" (or the user specifies such
> a thing), which schema takes precedence when?

It's up to the validator. The important reference here is Schema
Representation Constraint: Schema Document Location Strategy
(http://www.w3.org/TR/xmlschema-1/#schema_reference), which states:

 "Given a namespace name (or none) and (optionally) a URI reference from
  xsi:schemaLocation or xsi:noNamespaceSchemaLocation, schema-aware
  processors may implement any combination of the following strategies,
  in any order:

  1 Do nothing, for instance because a schema containing components
    for the given namespace name is already known to be available, or
    because it is known in advance that no efforts to locate schema
    documents will be successful (for example in embedded systems);

  2 Based on the location URI, identify an existing schema document,
    either as a resource which is an XML document or a <schema>
    element information item, in some local schema repository;

  3 Based on the namespace name, identify an existing schema
    document, either as a resource which is an XML document or a
    <schema> element information item, in some local schema

  4 Attempt to resolve the location URI, to locate a resource on the
    web which is or contains or references a <schema> element;

  5 Attempt to resolve the namespace name to locate such a resource.

  Whenever possible configuration and/or invocation options for
  selecting and/or ordering the implemented strategies should be

> 4. Imports and top elements: if schema 1 imports schema 2, can a
> global element from schema 2 kick off a document?

Hmm... interesting point. I think that the answer is yes, because the
physical schema documents are all merged into one logical schema (as
above), so there is no distinction between the schema actually
referenced from an instance document and one imported into that
referenced schema.



Jeni Tennison
Received on Saturday, 12 January 2002 07:55:33 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:55:54 UTC