This document is also available in these non-normative formats: XML.
Copyright © 2008 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This specification defines the interchange format for Service Modeling Language, Version 1.1 (SML) models. Markup is defined to identify the model being interchanged, to distinguish between model definition documents and model instance documents, and to bind rule documents with other documents in the interchange set.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This is the third Public Working Draft of the Service Modeling Language Interchange Format Version 1.1 specification for review by W3C members and other interested parties. It has been developed by the Service Modeling Language (SML) Working Group, which is a part of the Extensible Markup Language (XML) Activity.
The features and algorithms described in the normative portion of the document are specified in enough detail adequate for early implementation experiments.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
Comments on this document are invited and are to be sent to the public-sml@w3.org mailing list (public archive).
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
1. Introduction (Non-Normative)
2. Notations and Terminology
2.1 Notational Conventions
2.2 Terminology
3. Dependencies on Other Specifications
4. Informal Description (Non-Normative)
4.1 Packaging
4.2 URI References
4.3 Rule Document Bindings
4.4 Schema Document Bindings
5. SML Interchange Format Definition
5.1 Conformance Criteria
5.2 SML-IF Documents
5.2.1 Embedded Documents
5.2.2 Referenced Documents
5.3 URI References
5.3.1 URI equivalence
5.3.2 Document aliases
5.3.3 URI Reference Processing
5.4 Rule Document Bindings
5.4.1 URI prefix matching
5.4.2 Bindings defined
5.5 Schema Document Bindings
6. References
6.1 Normative
6.2 Non-Normative
A. SML-IF Schema
B. Localization of IF Identity Sample (Non-Normative)
As defined in the Service Modeling Language, Version 1.1 (SML) Specification [SML 1.1] an SML model is a collection of XML documents that may be used to describe complex services and systems such as a set of IT resources, services and their interrelations.
In every SML model there are two distinguished subsets of the model's documents, the definition documents and the instance documents. The model's definition documents describe the abstract structure of the model, and provide much of the information a model validator needs to decide whether the model as a whole is valid. The model's instance documents describe or support the description of the individual resources the model portrays.
The SML Specification identifies two categories of model definition documents that participate in model validation: Schema documents and rule documents. Schema documents in a model are XML documents that conform to the [SML 1.1] defined extensions to XML Schema [XML Schema Structures, XML Schema Datatypes]. Rule documents in a model include XML documents that conform to the [SML 1.1] defined extensions of Schematron [ISO/IEC 19757-3].
To ensure accurate and convenient interchange of the documents that make up an SML model or a portion of an SML model, it is useful to define an implementation-neutral interchange format that preserves the content and interrelationships among the documents. This specification defines a standard format called the SML Interchange Format (SML-IF) for this purpose.
The specification consists of two parts. The first part is an informal description of SML-IF to set the context. This is followed by SML-IF's normative definition.
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [IETF RFC 2119].
The content of this specification is normative except for sections, notes, or texts that are explicitly marked as non-normative. If a section is marked as non-normative, then all contained sub-sections are non-normative, even if they are not explicitly marked as such.
The SML-IF interchange set is the set of documents that constitute the SML model to be interchanged.
These terms are defined in the [SML 1.1] specification.
Other specifications on which this one depends are listed in [Normative_References].
Conforming implementations of this specification MUST support SML 1.1 [SML 1.1], XML 1.0 [XML] and XML Schema 1.0 [XML Schema Structures, XML Schema Datatypes]. Conforming implementations MAY additionally support later versions of the XML or XML Schema specifications.
Note:
This note is non-normative. Although SML 1.1 and SML-IF allow conforming implementations to support newer versions of dependent specifications, there are interoperability implications to be considered when documents based on those versions are interchanged using SML-IF. When an SML-IF document interchanges data built using newer versions of the SML and SML-IF dependent specifications, consumers of the SML-IF document not supporting these versions may be unable to interpret some of the data exchanged by this document.
To represent an SML model in a standard way for interchange, three topics need to be addressed.
Packaging: The collection of XML documents that make up a model (or model portion) to be interchanged need to be gathered together. In doing so, the model definition and model instance documents need to be distinguished from one another since they play distinct roles in the model.
Explicit references: The documents to be
interchanged may explicitly refer to one another and to documents that
are not packaged with the documents being interchanged. SML [SML 1.1] references
among SML model instance documents are an obvious example. Less
obvious are such references as certain xsi:schemaLocation
attributes in schema documents.
Binding of rule documents to the documents to which they apply: [SML 1.1] permits models in which rule documents apply to all, none, or subsets of the model's documents. SML-IF specifies how to describe which rule documents apply to which of the model's documents.
An SML-IF document packages a collection of SML documents to be interchanged as a single XML document. All SML-IF documents conform to the XML Schema defined in the normative part of this specification.
Informally, the structure of SML-IF documents, using the pseudoschema notation from WSDL 2.0 [WSDL 2.0 Core Language] is as follows:
<?xml version="1.0" encoding="UTF-8"?> <model xmlns="http://www.w3.org/2008/01/sml-if" xmlns:xs="http://www.w3.org/2001/XMLSchema"> <identity> <name> xs:anyURI Namespace identifying the model </name> <version> ? xs:token <!—The version of this model. E.g., 1.2 or 0.3> </version> <displayName smlerr:localizationid= "xs:anyURI URI identifying the translation resource for the display name" ?> ? xs:string Descriptive name of model intended for display <displayName/> <description smlerr:localizationid= "xs:anyURI URI identifying the translation resource for the description" ?> ? xs:string Textual description of model for human consumption <description/> </identity> <ruleBindings> ? <ruleBinding> * <documentAlias="xs:anyURI"/> ? <ruleAlias="xs:anyURI"/> </ruleBinding> </ruleBindings> <schemaBindings> ? <defaultSchema> ? <namespaceBinding/> * </defaultSchema> <schemaBinding> * <namespaceBinding/> * <documentAlias/> + </schemaBinding> </schemaBindings> <definitions schemaComplete="xs:boolean"> ? <document> * <docInfo> ? <aliases> ? <alias> * xs:anyURI A URI by which this document may be referred to </alias> </aliases> </docInfo> [ <data> xs:any <!—At most one definition document goes here> </data> | <locator> <documentURI/> ? xs:any <!—A reference to a definition document goes here> </locator> ] </document> </definitions> <instances> ? <document> * <docInfo> ? <aliases> ? <alias> + xs:anyURI A URI by which this document may be referred to </alias> </aliases> </docInfo> [ <data> xs:any<!—At most one instance document goes here> </data> | <locator> <documentURI/> ? xs:any <!—A reference to an instance document goes here> </locator> ] </document> </instances> </model>
The identity
element provides information applications
can use to identify and describe the set of SML documents being
interchanged.
The optional ruleBindings
element is used to contain
information that associates rule documents with the
documents they apply to. See 4.3 Rule Document Bindings
for further details.
The set of SML documents that are interchanged in an SML-IF
document is called the interchange set. Every document in the
interchange set appears as content of a document
element
in either the definitions
or the instances
element, depending on whether the document in question is a model
definition or a model instance document. There can be at most one
embedded document contained by a document/data
element.
Both definitions
and instances
are optional. So, for example, if there are
no model definition documents being packaged, the
definitions
element must be omitted.
The first child of each document
is typically a
docInfo
element that (indirectly) contains a list of
alias
elements whose content is a URI with no fragment
component (i.e., one with no "#" in it). Each of these URIs serves as
a name that other documents can use to refer to this
document. Examples of how aliases are used to handle certain URI-based
references are given in 4.2 URI References.
A document in the interchange set can be represented in either of
two ways, by embedding its content, or by providing a reference to
it. Which is being used is indicated by the next child of the
document
element. If the document is to be embedded, a
data
element is used to contain the actual content of the
document. If the document is to be referred to, a locator
element is used to contain the reference. Syntactically, the content
of a locator
can be a documentURI
element
defined by SML-IF or anything else understood by the
consumer. Typically it is a URI, an XLink [XLink], or
a Web Services Addressing endpoint reference [WS-Addressing Core].
Although it is not fully shown in the pseudo-schema above, the SML-IF schema has an "open content model." To provide extensibility, essentially every element in it can contain additional content and/or attributes from other XML namespaces.
When processing the SML model packaged inside an SML-IF document,
certain URI references (as defined in RFC 3986 [IETF RFC 3986])
may need to be processed to find their corresponding target.
For example, to assess SML validity of the interchanged model,
SML references using the URI scheme need to be resolved;
and to assemble a schema from multiple schema documents as part
of SML model validity assessment, the schemaLocation attribute
on an xs:include
element needs to be processed
to locate the schema document being included.
To see how these URI references are handled, consider the following SML-IF document:
<?xml version="1.0" encoding="UTF-8"?> <model xmlns="http://www.w3.org/2008/01/sml-if" version="1.0"> <identity> <name>http://www.university.example.org/sml/models/Sample/InterDocReferences</name> </identity> <definitions> <document> <data> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:include schemaLocation="http://www.university.example.org/university/enrollmodel.xsd"/> </xs:schema> </data> </document> </definitions> <instances> <document> <data> <Student xmlns="http://www.university.example.org/ns" xmlns:sml="http://www.w3.org/2007/09/sml"> <ID>1000</ID> <Name>John Doe</Name> <EnrolledCourses> <EnrolledCourse sml:ref="true"> <!-- Reference to a course Inside the interchange set --> <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> <EnrolledCourse sml:ref="true"> <!-- Reference to a course OUTside the interchange set --> <sml:uri> http://www.university.example.org/Universities/Capella/Courses.xml#xmlns(u=http://www.university.example.org/ns) xpointer(/u:Courses/u:Course[u:Name='LIT103']) </sml:uri> </EnrolledCourse> </EnrolledCourses> </Student> </data> </document> <document> <!-- One of the courses referenced above --> <docInfo> <aliases> <alias>http://www.university.example.org/Universities/MIT/Courses.xml</alias> </aliases> </docInfo> <data> <Courses xmlns="http://www.university.example.org/ns"> <Course> <Name>PHY101</Name> </Course> <Course> <Name>MAT200</Name> </Course> </Courses> </data> </document> </instances> </model>
Formal rules about how URI references are processed are defined
in section 5.3.3 URI Reference Processing. When not packaged
in an SML-IF document, certain URI references (e.g. values of sml:uri
elements or certain schemaLocation
attributes) are dereferenced to find
their corresponding document. When these references are packaged in an SML-IF document,
consumers of the SML-IF document need to first examine whether
the target document or element is packaged in the same SML-IF document.
To determine this, the fragment component, if any, is temporarily
ignored to form a URI. This URI is then compared against
alias
URIs of packaged model documents.
If the URI is equivalent to the URI in an
alias
(see 5.3.1 URI equivalence), the consumer will not
attempt to look for targets of this URI outside of the SML-IF document,
although there may exist a document retrievable at this URI. If
the original reference has a fragment, the fragment is applied to the
referred-to document to establish the reference target(s)
according to the corresponding reference scheme definition;
otherwise the reference is to the root element of the referred-to
document.
If the URI is not equivalent to the URI in any
alias
, then the SML-IF document does not contain
the corresponding target of the original reference. The consumer
may or may not attempt to look for targets outside of the SML-IF document,
depending on the nature of the reference.
Referring now to the example SML-IF document above. The reference:
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'])
, after removing the fragment, becomes
http://www.university.example.org/Universities/MIT/Courses.xml
, which is equivalent to the URI listed in the alias
accompanying the Courses
document. So, by applying the
fragment in the reference to the Courses
document, we
determine that the reference is to the Course
element
whose Name
element has "PHY101" as its content.
The fragment-free part of the reference:
http://www.university.example.org/Universities/Capella/Courses.xml#xmlns(u=http://www.university.example.org/ns) xpointer(/u:Courses/u:Course[u:Name='LIT103'])
is
http://www.university.example.org/Universities/Capella/Courses.xml
which is not equivalent to the URI in any alias
. This means
that it is an unresolved SML reference.
The URI:
http://www.university.example.org/university/enrollmodel.xsd
(value of the schemaLocation
attribute
on the include
element) is not equivalent to any alias
.
The consumer may or may not attempt to locate a schema document using this URI reference.
[SML 1.1] uses Schematron patterns embedded in SML schemas and in
separate explicitly bound rule documents to express constraints that
cannot be expressed in XML Schemas. Schematron patterns embedded in
SML Schema documents all have well defined targets. [SML 1.1] permits models
in which rule documents apply to all, none, or subsets of the model's
documents. SML-IF uses the list of ruleBinding
elements
contained in the optional ruleBindings
element to
associate rule documents with the documents in the interchange set to
which they apply. Each ruleBinding
associates the
documents having an alias beginning with the URI prefix given in the
documentAlias
with the rule documents having an alias
beginning with the prefix given in the ruleAlias
. So, for
example, the ruleBinding
:
<ruleBinding/> <documentAlias="http://www.university.example.org/sml/infrastructure/"/> <ruleAlias="http://www.university.example.org/sml/infrastructurerules/"/> </ruleBinding/>
Would associate documents that have the aliases such as:
http://www.university.example.org/sml/infrastructure/server427.xml
and
http://www.university.example.org/sml/infrastructure/switch6E.xml
with rule documents that have aliases such as:
http://www.university.example.org/sml/infrastructurerules/assetistracked.sch
and
http://www.university.example.org/sml/infrastructurerules/managedbycorporate.sch
SML-IF specifies rule bindings among documents in the interchange
set. It does not specify rule bindings that apply to documents not in
the interchange set. That said, it is often the case that the intent
of transferring an SML-IF document is to relate its contents with
other SML documents not in the interchange set. For example, the
intent might be to merge the interchange set with an existing SML
model. In such cases the context of use may choose to extend the
definition of ruleBinding
to bind documents not in the
interchange set. For example, if the interchange set is merged into an
existing model, the merge process might choose to extend the
definition of ruleBinding
elements to bind rule documents
in the interchange set to documents in the merged model that weren't
included in the interchange set.
Schema documents can be connected with other schema documents using composition
features provided by XML Schema. This includes xs:include
,
xs:redefine
, and xs:import
. A schema document's
validity may depend on other schema documents it includes/redefines/imports, or even
other schema documents that include/redefine/import it.
In performing SML model validation over the SML model packaged in an SML-IF instance,
associations between XML Schema definition documents and instance documents need to be
drawn, both to completely validate XML Schema documents themselves and to establish the
schema-validity of the instance documents.
The XML Schema 1.0 specification provides more flexibility in constructing the schema used for assessment than is appropriate for the semantics defined by SML and SML-IF validation.
It allows processor latitude in terms of locating schema documents (resolving namespace and schema location attributes) and composing schema documents together to form a single schema.
Schema location attributes can be ignored in some cases
(xsi:schemaLocation
in instance documents and
schemaLocation
attribute on xs:import
) and
allowed to "fail to resolve" in others (schemaLocation
attribute on xs:include
and xs:import
).
Multiple imports of the same namespace allow all but the first one to be ignored.
So it is clear that SML-IF cannot guarantee general case interoperability based only on XML Schema given the constraints above and, therefore, needs to specify how to determine such associations. This proposal concerns only SML model validation and not SML-IF validation (against the IF schema). Unless otherwise indicated, "validation" or "validity" in the following sections refers to SML model validation.
An SML-IF document can be:
Schema-complete - All schema documents are included in the SML-IF document, either as an 5.2.1 Embedded Documents or as 5.2.2 Referenced Documents.
Schema-incomplete - A required schema is not included in the SML-IF document, either as an embedded document or a referenced document.
It is necessary for an SML-IF producer to declaratively distinguish
between these two cases and that is not always possible
based on the content alone. SML-IF uses the schemaComplete
attribute on the definitions
element to indicate whether this
SML-IF document includes all necessary schema definition documents. When
this attribute is specified with a value of "true", then the schema validity of the
schema definition documents and instance documents depend only on
built-in components or components from definition
documents included in the SML-IF document. Built-in components include:
4 xsi: attributes (defined by XML Schema)
all schema built-in types (xs:anyType and simple types defined in XML Schema Part 2)
sml:ref attribute declaration
sml:uri element declaration
An SML model represented by a schema-incomplete SML-IF document is not necessarily invalid. However, SML-IF cannot guarantee interoperability for a schema-incomplete SML-IF document.
SML-IF uses a list of schemaBinding
elements
contained in the optional schemaBindings
element to
associate a namespace with a set of schema documents in the interchange set and
the instance documents
that should be validated against this set of schema documents.
Each namespaceBinding
child of a schemaBinding
element
associates the
namespace specified in its namespace
attribute
with the schema documents whose aliases are specified in its aliases
attribute.
In addition,
the instance documents that are to be assessed against this set of schemas are specified
in the documentAlias
child element of the same schemaBinding
element.
The following example illustrates schema bindings.
<schemaBindings> <!-- Each "schemaBinding" element corresponds to a schema and model instance documents that are assessed against this schema --> <schemaBinding> <!-- all "namespaceBinding" children together build the schema --> <namespaceBinding namespace="ns1" aliases="xsd1-a xsd1-b"/> <namespaceBinding namespace="ns2" aliases="xsd2-v1"/> <!-- list all applicable instances; same as for rule bindings --> <documentAlias>doc1</documentAlias> <documentAlias>doc2-v1-a</documentAlias> <documentAlias>doc2-v1-b</documentAlias> </schemaBinding> <schemaBinding> <namespaceBinding namespace="ns1" aliases="xsd1-a xsd1-b"/> <namespaceBinding namespace="ns2" aliases="xsd2-v2"/> <documentAlias>doc1</documentAlias> <documentAlias>doc2-v2</documentAlias> </schemaBinding> </schemaBindings> <definitions schemaComplete="true"> <!-- schema documents for xsd1-a, xsd1-b, xsd2-v1, xsd2-v2 --> </definitions>
There are cases where many instance documents use the same schema. In this case, it is
desirable to have a default schema binding rather than specifying a schemaBinding
that lists all these instance documents.
The defaultSchema
can be used cover to instance documents that are not included in
any otherschemaBinding
as in the following example.
<schemaBindings> <!-- The "defaultSchema" element corresponds to a schema that governs all instance documents *not* included in any "schemaBinding". --> <defaultSchema> <!-- all "namespaceBinding" children together build the schema --> <namespaceBinding namespace="ns1" aliases="ns1.xsd"/> <namespaceBinding namespace="ns2" aliases="ns2.xsd"/> </defaultSchema> </schemaBindings>
This section normatively defines the Service Modeling Language Interchange Format (SML-IF). It defines the requirements that SML-IF documents must adhere to and how URI references contained in them are to be interpreted by consumers of SML-IF documents.
SML-IF defines two levels of conformance for SML-IF Documents:
A level 2 conforming SML-IF Document MUST adhere to all requirements in this specification as described in the normative sections. In particular, all non-null SML references in the document MUST contain a URI scheme representation [SML 1.1].
A level 1 conforming SML-IF Document MUST adhere to all requirements in this specification as described in the normative sections with the exception that a URI scheme representation [SML 1.1] is not required for SML references. An SML-IF Document that contains at least one non-null SML reference which has no URI scheme representation but satisfies all other SML-IF requirements is a level 1 conforming SML-IF Document.
A conforming SML-IF Producer MUST be able to generate a level 2 conforming SML-IF Document from an SML model.
A conforming SML-IF Consumer MUST process a conforming SML-IF Document using, in whole or part, semantics defined by this specification. It is OPTIONAL that a conforming SML-IF Consumer process all elements defined in this specification, but any element that is processed MUST be processed in a manner that is consistent with the semantics defined here.
The purpose of SML-IF is to package the set of documents that constitute an SML model into a standard format so that it can be exchanged in a standard way.
An SML-IF document MUST conform to XML [XML] specification.
An SML-IF document MUST be valid under the XML Schema given in Appendix A.
An SML-IF document MAY form a valid SML model but it is not required to do so. Various uses of SML-IF may define requirements with respect to model validity and the interchange set, but this specification does not.
Each document in the interchange set MUST be represented in the SML-IF document by
a separate document
element as follows:
Each definition document
in the interchange set MUST appear as a descendant
of a model/definitions/document
element.
The order of the document
children is not significant.
Each instance document in the interchange set
MUST appear as a descendant of a model/instances/document
element. The order of
the document
children is not significant.
Each document in the interchange set MUST be included in the SML-IF document either as an embedded document (where the document to be included is embedded in the SML-IF document) or by including a reference to the document.
Documents that are to be embedded in the SML-IF document MUST be embedded as text or in an encoded format as follows:
If the document is embedded as text, it MUST be included as
the content of a
model/definitions/document/data
element if it is a definition document or a
model/instances/document/data
element if it is an instance document.
There MUST be at most one document embedded in each
model/*/document/data
element.
If the document is embedded in an encoded format, then the
octet stream representing the document MUST be
encoded in base64 format. The resultant data stream MUST be embedded as the
content of a model/definitions/document/base64Data
element if it is a
definition document or a
model/instances/document/base64Data
element if it is an instance document.
There MUST be at most one document embedded in each
model/*/document/base64Data
element.
Documents that contain a DTD MUST be embedded
in this encoded format.
When extracting an embedded document that is contained in a base64Data
element,
an SML-IF consumer MUST decode the content of the base64Data
element
first and then process the resulting document as an embedded instance document.
All embedded instance documents not encoded in base64 MUST
be processed as if they contained
the same DTD as the one specified on the model
element.
If model/*/document/data
contains no child element or
model/*/document/base64Data
has empty content then the SML-IF consumer
MUST treat the document as if it is not part of the
interchange set.
Documents that are to be referenced rather than embedded MUST be included as follows:
If the document is a definition document,
the location of the document MUST be included as the content of a
model/definitions/document/locator
element.
If the document is an instance document,
the location of the document MUST be included as the content of a
model/instances/document/locator
element.
SML-IF specifies one way
that MAY be used to provide the location of the
referenced document, the documentURI
element.
An SML-IF consumer MAY choose to locate a referenced document. If an SML-IF consumer chooses not to locate a referenced document or if it attempts to locate the referenced document and this attempt fails, then the SML-IF consumer MUST treat the referenced document as if it is not part of the interchange set. If either of these conditions occurs, the SML-IF consumer SHOULD make its invoker aware of this condition.
SML-IF uses URI equivalence extensively to handle references among documents in the interchange set. To determine whether two URIs are equivalent, consumers MUST perform case sensitive codepoint-by-codepoint comparison of the corresponding characters in the URI references.
In addition to containing or referring to one of the documents in
the interchange set, each document
element may
(indirectly) contain a list of alias
elements. Each
alias
contains a URI. The set of alias URIs for a given
document constitutes the set of identifiers by which documents in the
interchange set may have references to the document in question.
A document
element containing no alias
elements signals that the document in question has no aliases.
Each member of the set of all alias URIs in an SML-IF document MUST be unique. That is, no two alias URIs in a given SML-IF document may be equivalent.
Alias URIs MUST comply with the “absolute-URI” production as defined in RFC 3986 ([IETF RFC 3986]). This implies that they do not contain fragment components.
All alias
URIs in an SML-IF document MUST be unique.
When processing an SML-IF document, there are 3 categories of URI references that may need to be resolved:
schemaLocation
attributes on xs:include
and xs:redefine
in schema documents, when they are model definition documents.
Target-complete URIs [SML 1.1] used in SML reference schemes. For a URI reference to be in this category, its non-fragment URI components have all the information to uniquely identify at most one model document that potentially contains the target(s) of the URI reference.
URI references used in SML reference schemes which are not in category #2.
It is clear which references fall into category #1. An example of category #2 is URI references used in SML references that use the SML URI reference scheme. When new references schemes that use URI references are defined, whether they fall into category #2 or #3 will be clear from the reference scheme definitions. Resolution of URI references in category #3 is defined in their respective scheme definitions. It is also possible to have reference schemes that do not use URI references. Again, their resolution is governed by their scheme definitions and is not covered by this section.
To process a URI reference UR that is within categories #1 or #2 above, the following steps are performed:
Determine the document D that possibly contains the target:
If UR contains only a fragment component, then D is the model document that contains UR.
Otherwise
If UR has a fragment component, then let UR' be the URI referenced formed by removing the fragment component; otherwise let UR' be UR.
If UR' is a relative reference, then let B be the [base URI] ([XML Information Set]) property of the element information item containing UR, and transform UR' to form an (absolute) URI U, using B as the base URI, as defined in section “5 Reference Resolution” of RFC 3986 ([IETF RFC 3986]); otherwise let U be UR'.
If there exists a model document with an alias URI that is equivalent to U (5.3.1 URI equivalence), then D is that document; otherwise D has no value.
If D has no value, then
If UR is within category #1 (schemaLocation
),
then the SML-IF document does not contain the target schema document.
(Whether the consumer continues to dereference UR or U
is governed by other sections of this specification.)
Otherwise (R is within category #2, used in an SML reference) UR has no target.
If D is a schema document that is also a model definition document in the interchange set, then
If UR is within category #1 (schemaLocation
),
and it does not contain a fragment component,
then UR targets the root element of D.
Otherwise (UR contains a fragment component or is within category #2) UR has no target.
If D is a model instance document in the interchange set, then
If UR is within category #1 (schemaLocation
), then it has no target.
If UR does not contain a fragment component, then it targets the root element of D.
Otherwise (UR is within category #2 and contains a fragment component) the fragment component of UR is applied to the root element of D, which may result in 0, 1, or many target elements.
Otherwise (D is another kind of document in the interchange set) UR has no target.
To associate SML rule documents with the subset of documents in the model to which they apply, SML-IF uses a combination of the alias mechanism described above [5.3.2 Document aliases] and URI prefix matching.
Two URIs, one called the prefix, and one called the target participate in URI prefix matching. The target is said to match the prefix if and only if the target, truncated to the length of the prefix, is equivalent to the prefix as defined in section 5.3.1 URI equivalence.
A rule binding is an association of a set of one or more rule documents with a set of zero or more model documents. The documents associated with a given rule document are said to be "bound" to it. For a model to be valid, every document in the model must conform to the constraints defined by every rule document it is bound to. It is permissible for a rule document to have no bindings associated with it, and for a model document to be bound to zero rule documents.
The ruleBinding
element is used in SML-IF to express
rule bindings. In any given binding the set of rule documents is that
subset of rule documents in the interchange set with an alias that
matches the URI prefix given by the content of the
ruleAlias
element. The set of model documents in the
binding is that subset of the documents in the interchange set with an
alias that matches the URI prefix given by the content of the
documentAlias
element. If the documentAlias
element is omitted in a ruleBinding
, the set of model
documents in the binding is all documents in the interchange set.
Although SML-IF itself does not do so, various uses of SML-IF MAY choose to extend the sets of documents involved in bindings to include documents not contained in the interchange set. For example, if an SML-IF document is used to represent a model fragment that is intended to be merged with some other model, it is entirely possible that some or all of the bindings may involve not just the documents in the interchange set, but documents in the other model.
SML-IF consumers MAY choose to ignore the schemaBindings
element when present in the SML-IF document, in which case the consumer SHOULD
make its invoker aware of this situation. The remainder of this section applies to
SML-IF consumers who choose to process the schemaBindings
element.
For every schema binding SB in the model, i.e. every
/model/schemaBindings/schemaBinding
element, SML-IF consumers MUST perform the following steps
for instance document validation.
Compose a schema using all documents specified under all
SB's namespaceBinding
children.
Whenever an import
for a namespace N is encountered, perform the following steps.
If there is a namespaceBinding
child of SB whose
namespace
attribute matches N, then components from schema documents listed in the
corresponding aliases
attribute are used. As with rule bindings,
URI prefixing [5.4.1 URI prefix matching]
is used for matching schema document aliases.
At most one namespaceBinding
is allowed per namespace N within
a given SB. If more than one namespace binding exists for the namespace as part of
a single schema binding, the SML-IF document is in error.
If the set of aliases for namespace N is empty, the namespace has no schema
documents defining it in the schema binding.
Otherwise, if there are schema documents in the SML-IF document whose targetNamespace is N, then components from all those schema documents are used.
Otherwise, if this is a schema-complete SML-IF document
(/model/definitions/@schemaComplete
= "true"), then no component from N (other than built-ins) is included in
the schema being composed.
Otherwise, it is implementation-defined whether an SML-IF consumer tries to retrieve components for N from outside the SML-IF document.
Whenever an include
or redefine
is encountered,
the schemaLocation
is used to match aliases of schema documents, as with base SML-IF.
If there is a schema document in the SML-IF document matching that alias, then that document is used.
Otherwise, if this is a schema-complete SML-IF document, then the include
or
redefine
is unresolved (which is allowed by XML Schema
validity assessment rules).
Otherwise, it is implementation-defined whether an SML-IF consumer tries to resolve
include
or redefine
to schema documents outside the SML-IF document.
The instance documents that are referenced in the documentAlias
element of SB
MUST be validated
against the schema constructed in steps 1 through 3. sml:target*
and SML identity constraints can now be checked.
Similar to documentAlias
under ruleBinding
elements [5.4 Rule Document Bindings], each
documentAlias
can refer to multiple documents via URI prefixing.
If defaultSchema
is present, then an SML-IF consumer MUST
compose a default schema from this element
following rules 1 to 3 above. Otherwise, an SML-IF consumers MUST
compose a default schema using *all* schema documents
included in the SML-IF document. An SML-IF consumer MUST
use this default schema to validate those SML instance documents that are not
included in any schemaBinding
.
The common use case where match-all namespace matching is desired
can be achieved by omitting schemaBindings
without introducing any additional
complexity into the SML-IF document.
<?xml version="1.0" encoding="utf-8"?> <!-- /* * Copyright © 2008 World Wide Web Consortium, * * (Massachusetts Institute of Technology, European Research Consortium for * Informatics and Mathematics, Keio University). All Rights Reserved. This * work is distributed under the W3C® Document License [1] in the hope that * it will be useful, but WITHOUT ANY WARRANTY; without even the implied * warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. * * [1] http://www.w3.org/Consortium/Legal/2002/copyright-documents-20021231 */ --> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:smlif="http://www.w3.org/2008/01/sml-if" xmlns:ns1="http://www.w3.org/2008/01/sml-if" targetNamespace="http://www.w3.org/2008/01/sml-if" elementFormDefault="qualified" blockDefault="#all" version="1.0" xml:lang="EN" finalDefault="" attributeFormDefault="unqualified"> <xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd"/> <xs:element name="model" type="smlif:modelType"/> <xs:complexType name="modelType" mixed="false"> <xs:sequence> <xs:element name="identity" type="smlif:identityType"/> <xs:element ref="smlif:ruleBindings" minOccurs="0"/> <xs:element ref="smlif:schemaBindings" minOccurs="0"/> <xs:element name="definitions" type="smlif:documentCollectionType" minOccurs="0"/> <xs:element name="instances" type="smlif:documentCollectionType" minOccurs="0"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> <!-- If there is a need for localized string values, e.g. in displayName or description, the smlerr:localizationid global attribute can be used --> <xs:complexType name="identityType" mixed="false"> <xs:sequence> <xs:element name="name" type="smlif:uriType"/> <xs:element name="version" type="smlif:tokenType" minOccurs="0"/> <xs:element name="displayName" type="smlif:displayType" minOccurs="0"/> <xs:element name="description" type="smlif:displayType" minOccurs="0"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> <xs:complexType name="displayType" mixed="false"> <xs:simpleContent> <xs:extension base="xs:string"> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:extension> </xs:simpleContent> </xs:complexType> <xs:complexType name="tokenType" mixed="false"> <xs:simpleContent> <xs:extension base="xs:token"> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:extension> </xs:simpleContent> </xs:complexType> <xs:complexType name="uriType" mixed="false"> <xs:simpleContent> <xs:extension base="xs:anyURI"> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:extension> </xs:simpleContent> </xs:complexType> <xs:element name="ruleBindings" type="smlif:ruleBindingCollectionType"/> <xs:complexType name="ruleBindingCollectionType" mixed="false"> <xs:sequence> <xs:element ref="smlif:ruleBinding" maxOccurs="unbounded"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> <xs:element name="ruleBinding" type="smlif:ruleBindingType"/> <xs:complexType name="ruleBindingType" mixed="false"> <xs:sequence> <xs:element name="documentAlias" type="smlif:uriType" minOccurs="0"/> <xs:element name="ruleAlias" type="smlif:uriType"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> <xs:element name="schemaBindings" type="smlif:schemaBindingCollectionType"/> <xs:complexType name="schemaBindingCollectionType" mixed="false"> <xs:sequence> <xs:element ref="smlif:defaultSchema" minOccurs="0"/> <xs:element ref="smlif:schemaBinding" minOccurs="0" maxOccurs="unbounded"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> <xs:element name="schemaBinding" type="smlif:schemaBindingType"/> <xs:complexType name="schemaBindingType" mixed="false"> <xs:sequence> <xs:element ref="smlif:namespaceBinding"/> <xs:element name="documentAlias" type="smlif:uriType" minOccurs="0" maxOccurs="unbounded"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> <xs:element name="namespaceBinding" type="smlif:namespaceBindingType"/> <xs:complexType name="namespaceBindingType" mixed="false"> <xs:attribute name="namespace" type="xs:NCName" use="optional"/> <xs:attribute name="aliases" use="required"> <xs:simpleType> <xs:list itemType="xs:anyURI"/> </xs:simpleType> </xs:attribute> </xs:complexType> <xs:element name="defaultSchema" type="smlif:defaultSchemaType"/> <xs:complexType name="defaultSchemaType" mixed="false"> <xs:sequence> <xs:element ref="smlif:namespaceBinding" minOccurs="0" maxOccurs="unbounded"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> <xs:complexType name="documentCollectionType" mixed="false"> <xs:sequence> <xs:element ref="smlif:document" maxOccurs="unbounded"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="schemaComplete" type="xs:boolean"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> <xs:element name="document" type="smlif:documentType"/> <xs:complexType name="documentType" mixed="false"> <xs:sequence> <xs:element ref="smlif:docinfo" minOccurs="0"/> <xs:choice> <xs:element name="data" type="smlif:dataType"/> <xs:element name="base64Data" type="smlif:base64DataType"/> <xs:element name="locator" type="smlif:locatorType"/> </xs:choice> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> <xs:element name="docinfo" type="smlif:docinfoType"/> <xs:complexType name="docinfoType" mixed="false"> <xs:sequence> <xs:element ref="smlif:aliases" minOccurs="0"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> <xs:element name="aliases" type="smlif:aliasCollectionType"/> <xs:complexType name="aliasCollectionType" mixed="false"> <xs:sequence> <xs:element name="alias" type="smlif:uriType" maxOccurs="unbounded"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> <xs:complexType name="dataType" mixed="false"> <xs:annotation> <xs:documentation> The wildcard with processContents "skip" matches the root element of the model document being packaged. The value of processContents is set to "skip" so that the contained element is not processed for schema validation. As a result, validity of the packaged document will not affect validity of the IF document itself. </xs:documentation> </xs:annotation> <xs:sequence> <xs:any processContents="skip" minOccurs="0" namespace="##any" maxOccurs="1"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> <xs:complexType name="base64DataType" mixed="false"> <xs:simpleContent> <xs:extension base="xs:base64Binary"> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:extension> </xs:simpleContent> </xs:complexType> <xs:complexType name="locatorType" mixed="false"> <xs:sequence> <xs:element name="documentURI" type="smlif:uriType" minOccurs="0"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> </xs:schema>
The following example shows how the sml:locid
attribute
can be used to define the translation information for the interchange
set identity attributes:
<model xmlns="http://www.w3.org/2008/01/sml-if" version="1.0" xmlns:sml="http://www.w3.org/2008/01/sml"> xmlns:lang="http://www.university.example.org/translation/core"> <identity> <name sml:locid="lang:nameID“>Univerity interchange set</name> <description sml:locid="lang:descrID"> This document contains a list of universities.</description> </identity> </model>
In this example, the {namespace name} URI information of the
sml:locid
attribute can be used to define the location
for the resource containing the translated text.
The smlif:name
and smlif:description
elements
are using the same URI to identify the resource containing the translated strings:
<xmlns:lang="http://www.university.example.org/translation/core">
The {local part} information of the sml:locid
attribute can be
used to define the id of the text being translated. This information will
be used to locate the translation of the name and description texts
within the translation resource.