This document serves to publish RELAX NG schemas for XML Security specifications, including XML Signature 1.1, and XML Signature Properties.

This Working Draft collects non-normative RELAX NG Schemas for XML Security specifications, including XML Signature 1.1, XML Encryption 1.1, XML Security Generic Hybrid Ciphers and XML Signature Properties. The normative description of the respective data formats are included in the Recommendation-track Working Drafts.

These schemas are drafts and subject to further revisions. This is a work in progress. This document is intended to evolve to include additional RELAX NG schemas.

The changes to this document since the last publication on 16 March 2010 are the following:

• Removal of allowAny.rnc from Section 2, Included RNG Schema files.

• Added top-level schema any-containing-encryption.rng in section 6, XML Encryption 1.1 RNG Schema.

• Updated references.

• Some editorial updates to the document. Editorial changes to the detailed schema files referenced from the document.

A diff-marked version (diff-marked version) of this specification that highlights changes against the previous version is available.

Introduction

The XML Security specifications include normative XML Schema [[XMLSCHEMA-1]], [[XMLSCHEMA-2]]. This note provides non-normative RELAX NG schemas in compact form [[RELAXNG-SCHEMA]].

These RELAX NG schemas are highly modularized. This modularization has two significant advantages. First, it is easy to create schemas dedicated to enveloped or enveloping signatures. Second, it is easy to create schemas for imposing tight constraints where <xsd:any> in the original XSD schemas does not impose such tight constraints.

However, this modularization increases the number of schema modules.

First, a wildcard schema is needed for each core schema (e.g., xmldsig-core-schema.rnc (xmldsig-core-schema.rng) and xenc-schema.rnc (xenc-schema.rng)). Wildcard schemas mimic <xsd:any> in core schemas. A wildcard can be further customized by a driver schema or it can be simply replaced by another schema when tight constraints have to be hardcoded.

Second, one top-level schema is needed for each combination of core schemas and the choice from the "enveloping" and "enveloped" options. In this note, we only provide top-level schemas for enveloped signatures or encryptions, but it is easy to create top-level schemas for enveloping signatures.