Table of contents

Appendices

4.3 Layer 3: Schema Document Access and Web-interoperability

Layers 1 and 2 provide a framework for assessment and XML definition of schemas in a broad variety of environments. Over time, a range of standards and conventions may well evolve to support interoperability of XML Schema implementations on the World Wide Web. Layer 3 defines the minimum level of function required of all conformant processors operating on the Web: it is intended that, over time, future standards (e.g. XML Packages) for interoperability on the Web and in other environments can be introduced without the need to republish this specification.

Standards for representation of schemas and retrieval of schema documents on the Web[top]

For interoperability, serialized schema document, like all other Web resources, may be identified by URI and retrieved using the standard mechanisms of the Web (e.g. http, https, etc.) Such documents on the Web must be part of XML documents (see [c-vxd]), and are represented in the standard XML schema definition form described by layer 2 (that is as [schema] element information items).

NOTE: 

there will often be times when a schema document will be a complete XML 1.0 document whose document element is [schema]. There will be other occasions in which [schema] items will be contained in other documents, perhaps referenced using fragment and/or XPointer notation.

NOTE: 

The variations among server software and web site administration policies make it difficult to recommend any particular approach to retrieval requests intended to retrieve serialized schema document. An Accept header of application/xml, text/xml; q=0.9, */* is perhaps a reasonable starting point.

How schema definitions are located on the Web[top]

As described in [Layer 1: Summary of the Schema-validity Assessment Core], processors are responsible for providing the schema components (definitions and declarations) needed for assessment. This section introduces a set of normative conventions to facilitate interoperability for instance and schema documents retrieved and processed from the Web.

NOTE: 

As discussed above in [Layer 2: Schema Documents, Namespaces and Composition], other non-Web mechanisms for delivering schemas for assessment may exist, but are outside the scope of this specification.

Processors on the Web are free to undertake assessment against arbitrary schemas in any of the ways set out in [Assessing Schema-Validity]. However, it is useful to have a common convention for determining the schema to use. Accordingly, general-purpose schema-aware processors (i.e. those not specialized to one or a fixed set of pre-determined schemas) undertaking assessment of a document on the web must behave as follows:

• unless directed otherwise by the user, assessment is undertaken on the document element information item of the specified document;

• unless directed otherwise by the user, the processor is required to construct a schema corresponding to a schema document whose targetNamespace is identical to the namespace name, if any, of the element information item on which assessment is undertaken.

The composition of the complete schema for use in assessment is discussed in [Layer 2: Schema Documents, Namespaces and Composition] above. The means used to locate appropriate schema document(s) are processor and application dependent, subject to the following requirements:

1. Schemas are represented on the Web in the form specified above in [Standards for representation of schemas and retrieval of schema documents on the Web];

2. The author of a document uses namespace declarations to indicate the intended interpretation of names appearing therein; there may or may not be a schema retrievable via the namespace name. Accordingly whether a processor's default behavior is or is not to attempt such dereferencing, it must always provide for user-directed overriding of that default.

   NOTE: 

   Experience suggests that it is not in all cases safe or desirable from a performance point of view to dereference namespace names as a matter of course. User community and/or consumer/provider agreements may establish circumstances in which such dereference is a sensible default strategy: this specification allows but does not require particular communities to establish and implement such conventions. Users are always free to supply namespace names as schema location information when dereferencing is desired: see below.

3. On the other hand, in case a document author (human or not) created a document with a particular schema in view, and warrants that some or all of the document is conforms to that schema, the schemaLocation and noNamespaceSchemaLocation [attributes] (in the XML Schema instance namespace, that is, http://www.w3.org/2001/XMLSchema-instance) (hereafter xsi:schemaLocation and xsi:noNamespaceSchemaLocation) are provided. The first records the author's warrant with pairs of URI references (one for the namespace name, and one for a hint as to the location of a schema document defining names for that namespace name). The second similarly provides a URI reference as a hint as to the location of a schema document with no targetNamespace [attribute].

   Unless directed otherwise, for example by the invoking application or by command line option, processors should attempt to dereference each schema document location URI in the actual value of such xsi:schemaLocation and xsi:noNamespaceSchemaLocation [attributes], see details below.

4. xsi:schemaLocation and xsi:noNamespaceSchemaLocation [attributes] can occur on any element. However, it is an error if such an attribute occurs after the first appearance of an element or attribute information item within an element information item initially valid whose [namespace name] it addresses. According to the rules of [Layer 1: Summary of the Schema-validity Assessment Core], the corresponding schema may be lazily assembled, but is otherwise stable throughout assessment. Although schema location attributes can occur on any element, and can be processed incrementally as discovered, their effect is essentially global to the assessment. Definitions and declarations remain in effect beyond the scope of the element on which the binding is declared.

NOTE: 

Multiple schema bindings can be declared using a single attribute. For example consider a stylesheet:

 <stylesheet xmlns="http://www.w3.org/1999/XSL/Transform"
            xmlns:html="http://www.w3.org/1999/xhtml"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xsi:schemaLocation="http://www.w3.org/1999/XSL/Transform
                                http://www.w3.org/1999/XSL/Transform.xsd
                                http://www.w3.org/1999/xhtml
                                http://www.w3.org/1999/xhtml.xsd">

The namespace names used in schemaLocation can, but need not be identical to those actually qualifying the element within whose start tag it is found or its other attributes. For example, as above, all schema location information can be declared on the document element of a document, if desired, regardless of where the namespaces are actually used.

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 repository;

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.

Improved or alternative conventions for Web interoperability can be standardized in the future without reopening this specification. For example, the W3C is currently considering initiatives to standardize the packaging of resources relating to particular documents and/or namespaces: this would be an addition to the mechanisms described here for layer 3. This architecture also facilitates innovation at layer 2: for example, it would be possible in the future to define an additional standard for the representation of schema components which allowed e.g. type definitions to be specified piece by piece, rather than all at once.