Namespace Switchboard

Author:    Rick Jelliffe, Topologi pty. Ltd
Date:     2003-04-02

Copyright © 2003 Rick Jelliffe


Namespace Switchboard is a reformulation of James Clark's Modular Namespaces (MNS), with similar aims. Its advantage is, I believe, that is it clearer and simpler.

Namespace Switchboard can be summarized as follows. It

  • maintains the idea of validation subjects from MNS,
  • is couched in terms of properties of namespaces rather than validators,
  • divides the various "lax", "cover", "prune" and (to an extent) modes into orthogonal functions, giving more power and clarity,
  • copes with depth-interleaved namespaces,
  • adds support for namespace and schema versions,
  • limits modes and context, which belong in schema languages themselves, I tend to think, and which I believe may exclude the use of WXS, and
  • is simpler than MNS, which is so complex that it does not leave room for anything in Part 1.

Rather than saying "how do we validate?" the user asks the question "what do we do with (items in) this namespace?".

Validation Results

Every validation subject in a document can have a validation result attached, notionally. Before all validation, this value is "neutral". After validation, the value is "invalid" or "valid" or "neutral" ("neutral" at the end of validation is the same as WXS' "validationNotAttempted".) A validation subject can be forced to have a valid, invalid or neutral value, or the value can be determined by a schema: the default value of "check" means to use the schema.

A item marked invalid can never be un-invalidated, for example by some other schema.



I start giving the DTD, then an example, then explain it in detail after:

<!ELEMENT rule ( namespace+ )>
<!ELEMENT namespace ( alias*, schema*, namespace*)>
<!ATTLIST namespace
	ns  %uri;  #IMPLIED  
	result ( valid | invalid | none  | check ) check 
	preprocess ( keep | prune ) keep
	traversal  ( delve | skip | halt ) delve
<!ATTLIST alias
	uri %uri; #IMPLIED 
<!ELEMENT schema ANY>
<!ATTLIST schema	
	schema %uri; #IMPLIED  -- some kind of conref--
	schemaType CDATA #IMPLIED
	as  %uri; #IMPLIED  	

Preprocessing and Traversal

Traversal, validity assignment and preprocessing are conflated in WXS with the lax mode. We can unconflate them, and in so doing also provide limited namespace-based context and covering.

An invalid item does not cause validation to terminate necessarily. However, the traversal="halt" attribute causes validation to fail as soon as the subject is found.

The branch or document being presented for validation is first preprocessed: this may involve renaming namespaces, removing branches or attributes, or removing elements but promoting the contents. preprocess="prune" removes the validation subject. (If traversal="skip" it can remove the branch. If traversal="delve" it just removes the item and promotes any children as new validation subjects.)



Suppose we want to validate an XHTML document that uses RDF within its head element. (This is the same example as MNS, for contrast.) The following would do the job:

 1 <rules xmlns="" >
 2	<namespace ns="" >
 3		<schema uri="rdfxml.rng" />
 4		<namespace ns=""   
 5	  		preprocess="prune" 
 6	  		traversal="skip" />
 7	</namespace>
 9	<namespace ns="" >
10		<schema uri="xhtml.rng" />
11		<namespace ns="*" 
12				result="none" />
13	</namespace>



Line 1: Just as MNS, top-level is rules with a namespace.

Line 2: Rules contain namespace elements. Each namespace element binds the namespace to one or more schemas. If there is no uri specified, the no-namespace namespace is used. It is an error for more than one namespace binding for a given namespace.

This namespace element handles the XHTML elements.

Line 3: Namespace elements contain zero or more schema elements. Each schema used for validation. Schemas follow MNS with MIME types.

This schema is a RELAX NG schema.

Line 4: A namespace element can contain a nested namespace element. This specifies how to treat elements in different namespaces, from the point of view of the current schema. By default, the current schema will continue with all the descendents as candidates. If the nested namespace has a schema, it will be also run starting at the validation subject, in parallel with any other schemas.

This specifies how to handle RDF items inside XHTML. (Note, I do not attempt to provide context apart from namespace/namespace context.)

Line 5: The proprocess attribute says whether items in the new namespace should be pruned from the elements visible to the current validator or kept.

This specifies that RDF items should be pruned before they get to the XHTML validator.

Line 6: The traversal attribute signifies whether the element in the new namespace should be traversed into or skipped. (The other option "halt" is to enforce a draconian error detection policy.) If preprocess="prune" and traversal="enter" then the element is removed and its children promoted. (This covers the case where there are depth-wise interleaved elements from different namespaces.)

This specifies that RDF items should not be traversed into. The branch is removed.

Line 9: This specifies how the RDF namespace is handled when it appears anywhere. (Note: I do not attempt to provide a way to say "if this element has already been validated by some contextual schema, don't validate with this top-level namespace element.")

Line 10: The schema is RELAX NG again.

Line 11: If * is used as the namespace, it applies to all namespaces (apart from the current namespace or namespace elements declared in siblings).

This namespace rule applies to any items inside an RDF element which do not have an RDF namespace. (The usual distinction is drawn for attributes.)

Line 12: The result of "none" is set for validating these elements. Any other validation will override it. Because no preprocess attribute is specified, all subelements will be validated. Because no "traversal" is specified, validation continues into the subelements.



Because namespaces do not have an adequate versioning mechanism, it is difficult for people to upgrade their schemas. However, some people definitely wish to do this, and DSDL should provide a good mechanism.

Two mechanisms are provided: the alias elements and the as attribute.

The alias element gives namespace uris that should be mapped to the current namespace. For example, to say "if you find this old version of the namespace, validate it with the new validator".

The as attribute is a second namespace transformation. It works in reverse: the current namespace is mapped to a new one. This is used when you have various schemas that each use different versions of the namespace but which can all apply.


Inline Schemas

A schema can be specified inside the schema element. In that case there should be no uri attribute or schemaType attribute.

If the local name of the top-level element in a schema is "schema" it can be used. No sense in having <switch:schema><xsd:schema>