SML scenarios require several features that either do not exist or are not
fully supported in XML Schema. These features can be classified as
follows:
XML Schema supports two forms of extension: "attributes in different
namespace" and "application information elements"; both forms are used
by SML extensions.
3.1 References
XML documents introduce boundaries across content that needs to be
treated as a unit. XML Schema does not have any support for
inter-document references. SML extends XML Schema to support
inter-document references and a set of constraints on inter-document
references.
Support for inter-document references includes:
A new data type that
represents references to elements in other documents.
Multiple addressing
schemes for representing references.
Constraints on the type
of a referenced element.
The ability to define
key, unique, and key reference constraints across inter-document
references.
An SML reference is a link from one element to another. It can be
represented by using a variety of schemes, such as Uniform Resource
Identifiers (URIs) [IETF RFC 3986] and Endpoint References
(EPRs) [WS-Addressing Core]. SML does not mandate the use of
any specific scheme for representing references; implementations are
free to choose suitable schemes for representing
references. References MUST be supported by
model validators that conform
to this specification.
Reference elements MUST be identified by
sml:ref="true" or sml:ref="1" where
sml:ref is a global attribute whose declaration is as follows:
<xs:attribute name="ref" type="xs:boolean" />
An element that has sml:ref="true"
MUST be treated as a reference element, i.e., its
child elements MAY contain
one or more reference schemes. This mechanism enables schema-less
identification of reference elements, i.e., reference elements can be
identified without relying on PSVI.
The following example illustrates the use
of sml:ref. Consider the
following schema fragment:
<xs:element name="EnrolledCourse">
<xs:complexType>
<xs:sequence>
<xs:element name="Name" type="xs:string"/>
<xs:element name="Grade" type="xs:string"/>
<xs:any namespace="##any" minOccurs="0"
maxOccurs="unbounded" processContents="lax"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
</xs:element>
<xs:complexType name="StudentType">
<xs:sequence>
<xs:element name="ID" type="xs:string"/>
<xs:element name="Name" type="xs:string"/>
<xs:element name="EnrolledCourses" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element ref="tns:EnrolledCourse"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
The schema definition in the above example is
SML agnostic and does not make use of any SML attributes, elements, or types.
The EnrolledCourse element,
however, has an open content model and this can be used to mark instances
of EnrolledCourse as
reference elements as shown below:
<Student xmlns="http://www.university.example.org/ns"
xmlns:sml="http://www.w3.org/2007/08/sml"
xmlns:wsa="http://www.w3.org/2005/08/addressing">
<ID>1000</ID>
<Name>John Doe</Name>
<EnrolledCourses>
<EnrolledCourse sml:ref="true">
<Name>PHY101</Name>
<Grade>A</Grade>
<sml:uri>
http://www.university.example.org/Universities/MIT/Courses.xml#xmlns(u=http://www.university.example.org/ns)
xpointer(/u:Courses/u:Course[u:Name='PHY101'])
</sml:uri>
<wsa:EndpointReference>
<wsa:Address>http://www.university.example.org</wsa:Address>
</wsa:EndpointReference>
</EnrolledCourse>
<EnrolledCourse sml:ref="false">
<Name>MAT100</Name>
<Grade>B</Grade>
<sml:uri>
http://www.university.example.org/Universities/MIT/Courses.xml#xmlns(u=http://www.university.example.org/ns)
xpointer(/u:Courses/u:Course[u:Name='MAT100'])
</sml:uri>
</EnrolledCourse>
<EnrolledCourse>
<Name>SocialSkills</Name>
<Grade>F</Grade>
</EnrolledCourse>
</EnrolledCourses>
</Student>
The first EnrolledCourse element in the above example
is a reference element since it specifies
sml:ref="true". Assuming that references are
represented using URI and EPR schemes, it has two representations of the
reference to the element for course PHY101. The second and third
EnrolledCourse elements are not reference elements; the
second element specifies sml:ref="false" and
the third element does not specify the sml:ref
attribute. Note that the second element has a child element that
contains a reference scheme referring to course MAT100, but this reference will be
ignored since sml:ref="false" for the second
element.
A reference element MAY be empty or have a null
value provided that this is allowed by the element's schema. For
example, consider the following variation of the
EnrolledCourse element declaration:
<xs:element name="EnrolledCourse" nillable="true">
<xs:complexType>
<xs:sequence>
<xs:element name="Name" type="xs:string"/>
<xs:element name="Grade" type="xs:string"/>
<xs:any namespace="##any" minOccurs="0"
maxOccurs="unbounded" processContents="lax"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
</xs:element>
The above declaration allows null values for
instances of EnrolledCourse. Thus, an EnrolledCourse
reference element can have null value as shown in the following
example (the first EnrolledCourse
element has null value):
<Student xmlns="http://www.university.example.org/ns"
xmlns:sml="http://www.w3.org/2007/08/sml"
xmlns:wsa="http://www.w3.org/2005/08/addressing">
<ID>1000</ID>
<Name>John Doe</Name>
<EnrolledCourses>
<EnrolledCourse sml:ref="true" xsi:nil="true"/>
<EnrolledCourse sml:ref="false">
<Name>MAT100</Name>
<Grade>B</Grade>
<sml:uri>
http://www.university.example.org/Universities/MIT/Courses.xml#xmlns(u=http://www.university.example.org/ns)
xpointer(/u:Courses/u:Course[u:Name='MAT100'])
</sml:uri>
</EnrolledCourse>
<EnrolledCourse>
<Name>SocialSkills</Name>
<Grade>F</Grade>
</EnrolledCourse>
</EnrolledCourses>
</Student>
SML also supports several schema-based constraints on
reference elements. The sml:refType type has been defined to
allow model authors to make use of these schema-based constraints in
their model's schema. The definition of sml:refType fixes
the value of sml:ref to true, and hence all
elements of type sml:refType are reference elements.
The sml:refType is defined as follows:
<xs:complexType name="refType" sml:acyclic="false">
<xs:sequence>
<xs:any namespace="##any" minOccurs="0"
maxOccurs="unbounded"
processContents="lax"/>
</xs:sequence>
<xs:attribute ref="sml:ref" use="required"
fixed="true" />
<xs:anyAttribute namespace="##any"
processContents="lax"/>
</xs:complexType>
Note that
the above definition allows elements and attributes from any namespace to
occur in an element whose type is sml:refType. Thus, a scheme for reference elements
can be implemented by defining an
XML namespace for the scheme, and references can be represented in this
scheme by nesting element and attribute instances from this namespace as
attributes and children of sml:refType elements.
The
following example illustrates the use of sml:refType:
<xs:element name="EnrolledCourse" type="sml:refType" sml:targetType="tns:CourseType"/>
<xs:complexType name="StudentType">
<xs:sequence>
<xs:element name="ID" type="xs:string"/>
<xs:element name="Name" type="xs:string"/>
<xs:element name="EnrolledCourses" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element ref="tns:EnrolledCourse"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
The EnrolledCourse
element declaration is of
type sml:refType which marks it as a
document reference, and this element declaration is used in
StudentType to reference the elements
corresponding to the courses in which a student is enrolled.
Examples of the use of sml:refType for
EnrolledCourse are found in the section 3.2 Reference Schemes. This section demonstrates the use of the
URI and EPR schemes to define the reference.
3.1.1 Reference Definitions
3.1.1.1 SML Reference
An element that has either sml:ref="true" or sml:ref="1" specified.
Although either sml:ref="true" or
sml:ref="1" can be used to identify an SML reference element,
for the sake of brevity and consistency, the rest of this specification uses
sml:ref="true" in examples and other definitions.
3.1.1.2 Null Reference
A reference element with xsi:nil="true" or no content, provided
that it is allowed by the element's declaration.
3.1.1.3 Dangling Reference
A non-null reference whose target does not exist.
3.1.2 Reference Semantics
3.1.2.1 At Most One Target
Every reference element MUST target (or resolve to)
at most one element in a model.
Dangling references are allowed in SML; therefore it is possible that the
target of a reference does not exist in a model. It is an error if a
reference element targets more than one element in a model.
If a single reference element has multiple representations,
every representation MUST target the same element. Validators MAY check
this condition.
3.1.2.2 Multiple References
An element in a document MAY be targeted by multiple reference elements.
These reference elements may use different schemes and/or be expressed in different ways.
3.1.2.3 Empty or Null References
A model validator
MUST not perform the SML validation associated with references for a null reference element.
3.1.2.4 deref() XPath Extension Function
Each model validator MUST provide an
implementation of the deref() XPath extension function
that is capable of resolving references expressed in the model
validator's chosen scheme(s). This function takes a node-set of
elements and returns a node-set consisting of element nodes
corresponding to the elements referenced by the input node set. In
particular, for each node R in the input node set the output
node set contains at most one element node.
The output node set
contains one element node for R provided that all of the following conditions are
true
The output node set
contains no element node corresponding to R if any of the following conditions is true
the target of
R is not in the model
R is
an empty or null reference
R does not contain any reference scheme that is understood
by the implementation
sml:ref is not specified for R
sml:ref is specified for R and its value is neither "true" nor "1".
3.2 Reference Schemes
A reference MAY be represented by using a variety of schemes, and SML does
not mandate the use of any specific schemes. Uniform Resource Identifiers
(URIs) [IETF RFC 3986] and endpoint references (EPRs) [WS-Addressing Core] are two common schemes for
referencing resources. Although SML does not require the use of either
scheme, it does define how a reference MUST be represented using the URI
scheme and the EPR scheme.
3.2.1 URI Scheme
References that are represented using the URI scheme
MUST be implemented by using the
sml:uri global element as a child of reference elements,
i.e., elements for which sml:ref="true". More precisely,
if a model validator chooses to represent references using the URI
scheme,
It MUST represent each reference using
an instance of the sml:uri global element declaration
as a child of the reference element.
It MUST treat each instance of the
sml:uri global element declaration, whose parent
element is a reference element, as a reference represented in the
URI scheme.
For example, if the reference element in 3.1 References
is represented using the URI scheme, an instance of
EnrolledCourse will appear as follows:
<EnrolledCourse xmlns="http://www.university.example.org/ns" sml:ref="true">
<sml:uri>http://www.university.example.org/someUri</sml:uri>
</EnrolledCourse>
where http://www.university.example.org/someUri is a
valid URI as defined in [IETF RFC 3986].
Suppose that a model has the
following documents, and each document has an associated URI:
| Document | URI |
|---|
| Course PHY101 | http://www.university.example.org/Universities/MIT/Courses/PHY101.xml |
| Course MAT200 | http://www.university.example.org/Universities/MIT/Courses/MAT200.xml |
| Student 1000 | http://www.university.example.org/Universities/MIT/Students/1000.xml |
| Student 1001 | http://www.university.example.org/Universities/MIT/Students/1001.xml |
The following is a sample instance document for Student
1000 where the references are represented in the URI scheme:
<Student xmlns="http://www.university.example.org/ns">
<ID>1000</ID>
<Name>John Doe</Name>
<EnrolledCourses>
<EnrolledCourse sml:ref="true">
<sml:uri>http://www.university.example.org/Universities/MIT/Courses/PHY101.xml</sml:uri>
</EnrolledCourse>
<EnrolledCourse sml:ref="true">
<sml:uri>http://www.university.example.org/Universities/MIT/Courses/MAT200.xml</sml:uri>
</EnrolledCourse>
</EnrolledCourses>
</Student>
3.2.1.1 Fragment Identifier
Fragment identifiers in references that are represented using the
URI scheme MUST use the following XPointer [XPointer] profile: Only two schemes – xmlns() [xmlns() Scheme] and xpointer() [xpointer() Scheme] –
are supported.
The expression specified
for the xpointer scheme MUST be a restricted XPath 1.0 [XPath 1.0] expression
that MUST resolve to at most one element node. In particular, this
expression MUST NOT contain
This expression can only use the functions defined in the
XPath 1.0 core function library [XPath 1.0]. It
MUST NOT use the smlfn:deref
function and/or the following functions defined for xpointer()
scheme [xpointer() Scheme]:
range-to
string-range
range
range-inside
start-point
end-point
here
origin
The following example illustrates the use of xpointer
fragments. Consider the case where all courses offered by MIT are stored in a
single XML document – Courses.xml –
whose URI is http://www.university.example.org/Universities/MIT/Courses.xml. In this case, the element inside
Courses.xml that corresponds to the course
PHY101 can be referenced as follows (assuming that Coursesis the root element in
Courses.xml)
<Student xmlns="http://www.university.example.org/ns">
<ID>1000</ID>
<Name>John Doe</Name>
<EnrolledCourses>
<EnrolledCourse sml:ref="true">
<sml:uri>
http://www.university.example.org/Universities/MIT/Courses.xml#xmlns(u=http://www.university.example.org/ns)
xpointer(/u:Courses/u:Course[u:Name='PHY101'])
</sml:uri>
</EnrolledCourse>
</EnrolledCourses>
</Student>
A reference element can also be used to
reference an element in its own document. To see this consider the following
instance document
<University xmlns="http://www.university.example.org/ns">
<Name>MIT</Name>
<Courses>
<Course>
<Name>PHY101</Name>
</Course>
<Course>
<Name>MAT200</Name>
</Course>
</Courses>
<Students>
<Student>
<ID>123</ID>
<Name>Jane Doe</Name>
<EnrolledCourses>
<EnrolledCourse sml:ref="true">
<sml:uri>
#xmlns(u=http://www.university.example.org/ns)
xpointer(/u:University/u:Courses/u:Course[u:Name='MAT200']
</sml:uri>
</EnrolledCourse>
</EnrolledCourses>
</Student>
</Students>
</University>
Here, the EnrolledCourse element for the student
Jane Doe references the Course element for MAT200 in
the same document.
3.2.2 EPR Scheme
References that are represented using the EPR scheme MUST be implemented
by using instances of wsa:EndpointReference global element declaration [WS-Addressing Core] as
child elements of reference elements. The following example illustrates
how the EnrolledCourse reference that references course PHY101 in MIT university can be
represented using the EPR scheme:
[Example Under Construction]
<EnrolledCourse xmlns="http://www.university.example.org/ns" sml:ref="true">
<wsa:EndpointReference
xmlns:u="http://www.university.example.org/schema">
<wsa:Address>http://www.university.example.org</wsa:Address>
</wsa:EndpointReference>
</EnrolledCourse>
3.3 Constraints on References
SML supports the following attributes for expressing constraints on reference elements.
Table 3-1. Attributes| Name | Description |
|---|
sml:acyclic
| Used to specify whether cycles are supported for a reference. |
sml:targetElement
| Used to constrain the name of the reference's target element. |
sml:targetType
| Used to constrain the type of the reference's target element. |
sml:targetRequired
| Used to specify that a reference's target element is required
to be present in the model. |
These attributes MUST be supported in the following specified locations only in an SML model:
These attributes MUST be supported in XML Schema documents.
These attributes MUST be supported for element declarations of
type sml:refType or a derived type of sml:refType.
Note that this specification specifies sml:acyclic="false" for
type sml:refType.
3.3.1 sml:acyclic
Model validators that conform to this specification MUST support the
sml:acyclic attribute on derived types of
sml:refType. This is a boolean attribute and its value can be
either true or false. Let R be a
derived type of sml:refType. If
sml:acyclic="true" is specified for R, then
R is an acyclic reference type, i.e., instances of
R MUST NOT create cycles in any model. More precisely,
the directed graph whose nodes are documents that contain the source or
target elements for instances of R, and whose
edges are instances of R (an edge is directed
from the document containing the source element to the document containing
the target element), must be acyclic.
A cyclic reference type can be used to derive cyclic or acyclic reference
types, but all derived types of an acylic reference type are acyclic. Model
validators that conform to this specification MUST enforce the following:
If CR is a cyclic reference
type and DCR
is a derived type of
CR, then DCR
is an acyclic
reference if sml:acyclic="true" is specified for
DCR
. Otherwise,
DCR
is a cyclic reference
If AR is an acyclic
reference type and DAR
is a derived type of
AR, then sml:acyclic="true" holds for
DAR
even if the sml:acyclic
attribute is not explicitly specified for
DAR
. It is an error for
DAR
to specify
sml:acyclic="false"
3.3.2 Constraints on Targets
SML supports three attributes: sml:targetElement,
sml:targetRequired, and sml:targetType, for
constraining the target of a reference. These three attributes are
collectively called sml:target* attributes and they MUST be
supported on global and local element declarations. Model validators that
conform to this specification MUST enforce the following:
If one/more of sml:target* attributes are specified (either
explicitly or by default) for a particle
P in a complex-type definition CT, then all
particles in CT that have the same name as
P must specify the same set of sml:target*
attributes as P and these attributes must have the same
values as those specified for P.
In particular, all of the following must be enforced:
If
sml:targetElement="ns:GTE" for P then
sml:targetElement="ns:GTE" for all particles in
CT that have the same name as P
If
sml:targetRequired="true" for P then
sml:targetRequired="true" for all particles in
CT that have the same name as P
If
sml:targetRequired="false" for P then
sml:targetRequired="false" for all particles in
CT that have the same name as P
If
sml:targetType="ns:T" for P then
sml:targetType="ns:T" for all particles in
CT that have the same name as P
The above conditions on the use of sml:target*
attributes have been defined to reduce the implementation burden on
model validators for
verifying that the use of sml:target* attributes is
consistent across derivation by restriction. These conditions enable
model validators to find the restricted particle for a restricting
particle using a simple name match when sml:target*
attributes are specified for these particles. In the absence of the
above conditions, it is extremely difficult for SML validators to
verify consistent use of sml:target* attributes across a
base type and its restricted derived type. In order to verify
consistent use of an sml:target* attribute on a
restricted particle in the base type and its restricting particle in a
restricted derived type, it is necessary to connect the particles in
the derived type with those from the restricted base type. However,
this level of support is not provided by most XML Schema frameworks;
thus most SML validators would otherwise need to duplicate large parts
of XML Schema's compilation logic to verify consistent usage of
sml:target* attributes across derivation by
restriction.
3.3.2.1 sml:targetElement
Model validators that conform to this specification MUST support the
sml:targetElement attribute on element declarations whose type
is sml:refType or a derived type of sml:refType.
The value of this attribute MUST be the qualified name of some global element
declaration. Let sml:targetElement="ns:GTE" for some element
declaration E. Then each element instance of
E MUST reference an element that is an instance of
ns:GTE or an instance of some global element declaration in
the substitution group hierarchy whose head is ns:GTE. If a
target element constraint is specified for a global element declaration
G then it continues to apply to all global element
declarations in the substitution group hierarchy whose head is
G. However, a global element declaration in
G's substitution group can specify a target element
constraint that refines the constraint defined for G. In
particular, model validators that conform to this specification MUST enforce
the following:
If a target element constraint is specified for a particle
P in some type B, then it continues to apply
to each particle PR
that is a valid
restrictions of P where PR
is
defined in some restricted derived type of B (see
"
Schema
Component Constraint: Particle Valid (Restriction)
", section
3.9.6, "Constraints on Particle Schema Components",
[XML Schema Datatypes] for XML Schema's definition of valid
restrictions). However, PR
can
specify a target element constraint that refines the constraint
defined for P. In particular, model validators that
conform to this specification MUST enforce the
following:
If
sml:targetElement="ns:GTE" is specified for
P and sml:targetElement is specified for
PR
, then the value of
sml:targetElement for PR
must be
ns:GTE or the name of a global element declaration in
the substitution group hierarchy whose head is ns:GTE.
If sml:targetElement is not specified for
PR
, then
sml:targetElement="ns:GTE" holds for
PR
by default.
3.3.2.2 sml:targetRequired
Model validators that conform to this specification MUST support the
sml:targetRequired attribute on element declarations whose
type is sml:refType or a derived type of
sml:refType. If sml:targetRequired
="true" for an element declaration E, then
each element instance of E MUST target some element in the
model, i.e., no instance of E can be null, empty, or contain
a dangling reference. Otherwise, instances of E can be
empty, null, or contain dangling references. If this attribute is not
specified, then its value is assumed to be "false".
Model validators that conform to this specification MUST enforce the
following:
If the sml:targetRequired
attribute is specified for a global element declaration
G then the specified value applies by default to each
global element declaration SG
in the
substitution group hierarchy whose head is G unless the
sml:targetRequired attribute is specified for
SG
.
If
sml:targetRequired="true" is specified for a global
element declaration G then
sml:targetRequired="false" MUST NOT be specified for
any element declaration in the substitution group hierarchy whose head is
G.
If sml:targetRequired attribute
is specified for a particle P in some type
B, then the specified value applies by default to to
each particle PR
that is a valid restriction
of P unless the sml:targetRequired
attribute is specified for PR
(see "
Schema
Component Constraint: Particle Valid (Restriction)
", section
3.9.6, "Constraints on Particle Schema Components",
[XML Schema Datatypes]
for XML Schema's definition of valid restrictions).
If sml:targetRequired="true" for a particle P then
sml:targetRequired="false" MUST NOT be specified for any
particle PR
that is
a valid restriction of P.
3.3.2.3 sml:targetType
The sml:targetType attribute MUST
be supported on element declarations whose type
is sml:refType or a derived type of sml:refType.
The value of this attribute MUST be the qualified name of some type
definition. Let sml:targetType="ns:T" for some element
declaration E. Then each element instance of
E MUST reference an element whose type is
ns:T or a derived type of ns:T.
If a target type constraint is specified for a global element declaration
G then it continues to apply to all global element
declarations in the substitution group hierarchy whose head is
G. However, a global element declaration in
G's substitution group can specify a target type
constraint that refines the constraint defined for G. In
particular, model validators that conform to this specification MUST enforce
the following:
If the target type constraint is specified for a particle
P in some type B, then it continues to
apply to each particle PR
that is a valid
restriction of P where PR
is
defined in some restricted derived type of B. However,
PR
can specify a target type constraint that
refines the constraint defined for P. In particular, model
validators that conform to this specification MUST enforce the following:
3.4 Identity Constraints
XML Schema supports the definition of key, unique, and key reference
constraints through xs:key, xs:unique, and
xs:keyref elements. However, the scope of these constraints is
restricted to a single document. SML defines analogs for these constraints,
whose scope extends to multiple documents by allowing them to traverse
inter-document references.
Model validators that conform to this specification MUST support the
following elements for defining identity constraints across references:
| Name | Description |
|---|
sml:key
| Similar to xs:key except that the selector and
field XPath expression can use smlfn:deref function |
sml:unique
| Similar to xs:unique except that the selector and
field XPath expression can use smlfn:deref function |
sml:keyref
| Similar to xs:keyref except that the selector and
field XPath expression can use smlfn:deref function |
The syntax and semantics of the above elements are according to Section 3.11.2 of the XML Schema specification [XML Schema Datatypes], except for the following:
If an SML identity constraint needs to be
specified for an element declaration E, then it MUST be
defined in the xs:annotation/xs:appinfo
descendant element for the xs:element element for
E
An SML identity constraint that is specified
for an element declaration E can reuse the definition
of an SML identity constraint ID' specified for some
other element declaration E' by specifying the name of
E' as the value of its ref attribute. In
particular,
If the ref attribute is
specified for an SML identity constraint
element that is specified for an element declaration
E, then the value of ref attribute MUST
NOT be name of any other SML identity constraint element specified
for E.
If the ref attribute is
specified for an sml:key element, then the value of
ref attribute MUST be name of another SML key
constraint
If the ref attribute is
specified for an sml:unique element then the value of
the ref attribute MUST be name of another SML unique
constraint
If the ref attribute is
specified for an sml:keyref element then the value of
the ref attribute MUST be name of another SML keyref
constraint
If the ref attribute is
specified for an SML identity constraint, then the name
attribute MUST NOT be specified
If the ref attribute is
specified for an SML identity constraint, then the
selector and field
child elements MUST NOT be specified
If an SML identity constraint is specified for an element
declaration E, then this constraint is applicable to all
instances of E in a model, i.e., the identity constraint
MUST be satisfied for each instance of E
in a valid model
The sml:selector XPath
expression MUST conform to the following extended BNF
Selector ::= Path ( '|' Path)*
Path ::= ('.//')? Step ( '/' Step)* | DerefExpr
DerefExpr ::= (NCName ':')? 'deref(' Step (/Step)* ')' ('/'Step)* |
(NCName ':')? 'deref(' DerefExpr ')' (/Step)*
Step::= '.' | NameTest
NameTest ::= QName |'*' | NCName ':' '*'Path::= ('.//')? ( Step '/')* ( Step | @NameTest ) |
DerefExpr ('/' @NameTest)?Each SML identity constraint that is
specified for a global element declaration G MUST be
treated as if it is specified by default for all global element
declarations SG
that are in the substitution
group hierarchy whose head is G
Each SML identity
constraint that is specified for a particle P in
a complex-type definition CT MUST be
treated as if it is specified by default for all particles
PR
in restricted derived
types of CT that are a valid
restriction of P
If one/more SML identity constraints are
specified (either explicitly or by default) for a particle
P in a complex-type definition CT, then
all particles in CT that have the same name
as P MUST specify the same set of identity constraints as P. This rule
is defined to reduce the implementation burden for model validators. It
facilitates the matching of restricting and restricted particles using
their names, and avoids the replication of large parts of XML Schema's
compilation logic for this purpose.
3.4.1 University Example
The following example will be used to illustrate the sml:key,
sml:unique, and sml:keyref constraints across
references.
<xs:element name="Student"
type="sml:refType"
sml:targetType="tns:StudentType"/>
<xs:element name="Course"
type="sml:refType"
sml:targetType="tns:CourseType"/>
<xs:complexType name="UniversityType">
<xs:sequence>
<xs:element name="Name" type="xs:string"/>
<xs:element name="Students" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element ref="tns:Student" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="Courses" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element ref="tns:Course" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:element name="EnrolledStudent"
type="sml:refType"
sml:targetType="tns:StudentType"/>
<xs:element name="EnrolledCourse"
type="sml:refType"
sml:targetType="tns:CourseType"/>
<xs:complexType name="StudentType">
<xs:sequence>
<xs:element name="ID" type="xs:string"/>
<xs:element name="SSN" type="xs:string" minOccurs="0"/>
<xs:element name="Name" type="xs:string"/>
<xs:element name="EnrolledCourses" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element ref="tns:EnrolledCourse"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="CourseType">
<xs:sequence>
<xs:element name="Name" type="xs:string"/>
<xs:element name="EnrolledStudents" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element ref="tns:EnrolledStudent"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
3.4.2 sml:key and sml:unique
XML Schema supports key and uniqueness constraints through
xs:key and xs:unique, but these constraints can
only be specified within a single XML document. The sml:key and
sml:unique elements support the specification of key and
uniqueness constraints across documents. We'll use the UniversityType (see 3.4.1 University Example)
definition to illustrate this concept. It is reasonable to expect that each
student in a university must have a unique identity, and this identity must
be specified. This can be expressed as follows:
<xs:element name="University" type="tns:UniversityType">
<xs:annotation>
<xs:appinfo>
<sml:key name="StudentIDisKey">
<sml:selector xpath="smlfn:deref(tns:Students/tns:Student)/tns:ID"/>
<sml:field xpath="."/>
</sml:key>
</xs:appinfo>
</xs:annotation>
</xs:element>
The sml:key and sml:unique constraints are
similar but not the same. sml:key requires that the specified
fields must be present in instance documents and have unique values, whereas
sml:unique simply requires the specified fields to have unique
values but does not require them to be present in instance documents. Thus
keys imply uniqueness, but uniqueness does not imply keys. For example,
students in a university must have a unique social security numbers, but the
university may have foreign students who do not possess this number. This
constraint can be specified as follows:
<xs:element name="University" type="tns:UniversityType">
<xs:annotation>
<xs:appinfo>
<sml:unique name="StudentSSNisUnique">
<sml:selector xpath="smlfn:deref(tns:Students/tns:Student)"/>
<sml:field xpath="tns:SSN"/>
</sml:unique>
</xs:appinfo>
</xs:annotation>
</xs:element>
The sml:key and sml:unique constraint
are always specified in the context of a scoping element. In the above
example, the University element declaration is the
context for the key and unique constraints.
The following example illustrates the use of the ref
attribute in an SML identity constraint:
<xs:element name="PrivateUniversity" type="tns:UniversityType">
<xs:annotation>
<xs:appinfo>
<sml:unique ref="tns:StudentSSNisUnique"/>
</xs:appinfo>
</xs:annotation>
</xs:element>
In the above example, the PrivateUniversity element
declaration specifies the StudentSSNisUnique unique
constraint by referencing its definition in the
University element declaration.
3.4.3 sml:keyref
XML Schema supports key references through xs:keyref to
ensure that one set of values is a subset of another set of values within an
XML document. Such constraints are similar to foreign keys in relational
databases. Key references in XML Schema are only supported within a single
XML document. The sml:keyref element allows key references to be
specified across XML documents, and can be used to scope references to point
to elements within a valid range. The following example uses
sml:keyref to capture the requirement that courses in a
university can only enroll students from the same university:
<xs:element name="University" type="tns:UniversityType">
<xs:annotation>
<xs:appinfo>
<sml:key name="StudentIDisKey">
<sml:selector xpath="smlfn:deref(tns:Students/tns:Student)"/>
<sml:field xpath="tns:ID"/>
</sml:key>
<sml:keyref name="CourseStudents" refer="tns:StudentIDisKey">
<sml:selector xpath="smlfn:deref(
smlfn:deref(tns:Courses/tns:Course)/
tns:EnrolledStudents/tns:EnrolledStudent)"/>
<sml:field xpath="tns:ID"/>
</sml:keyref>
</xs:appinfo>
</xs:annotation>
</xs:element>
The above constraint specifies that for a university, the set of IDs of
students enrolled in courses is a subset of the set of IDs of students in a
university. In particular, the selector and field
elements in StudentIDisKey key constraint identify the set of
IDs of students in a university, and the selector and
field elements in CourseStudents key reference
constraint identify the set of IDs of students enrolled in courses.