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 SML 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 both an
implementation-neutral interchange format that preserves the content and
interrelationships among the documents and a constrained form of
SML model validation. For this purpose, Tthis
specification defines a standard format called the SML Interchange Format
(SML-IF) and a process called interchange set validation.
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.
Definition document, instance document, rule document
These terms are defined in the [SML
1.1] specification.
Interchange set validation
Interchange set validation is the
process of verifying that the interchange set is valid with respect to the SML
model validation and that it respects all assertions and interrelationships among the documents as
defined by the SML-IF 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, several 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
1.1] SML references among SML model instance documents are an
obvious example. Less obvious are such references as certain schemaLocation
attributes in schema documents and xsi:schemaLocation
attributes in instance documents. Section 4.4
Schema Document Bindings defines how schemaLocation is processed in
these cases.
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.
Getting
consistent model validation results: The process of SML model
validation defined in [SML
1.1] contains points of variability that, left unconstrained, would
make it difficult for SML-IF to ensure interoperability of independent
implementations in any practical way.
Many of these sources of variability are inherited from other
specifications that SML uses, e.g. URI comparison [RFC 3986] and the source of
Schema components [XML Schema 1.0] used to validate model instance
documents. SML-IF constrains these points
of variability, sometimes globally and sometimes based on specific assertions
about the interchange set represented by a specific SML-IF document, with the
goal of ensuring interoperability when specific conditions are met and of
increasing the likelihood of interoperability in other cases. The enforcement of these additional
constraints on SML model validation occurs during the process of interchange
set validation.
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 pseudo-schema 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/@@@@/@@/sml-if"xmlns:xs="http://www.w3.org/2001/XMLSchema"
SMLIFVersion="xs:token Version number of the SML-IF spec used to generate the current document">
<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 sml:locid=
"xs:anyURI URI identifying the translation
resource for the display name" ?> ?
xs:string Descriptive name of model intended for display
<displayName/>
<description sml:locid=
"xs:anyURI URI identifying the translation
resource for the description" ?> ?
xs:string Textual description of model for human consumption
<description/><baseURI>
xs:anyURI <!-Base URI for relative URI or IRI references defined in the interchange set->
</baseURI> ?
</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 primaryAlias=”xs:boolean”> *xs:anyURI - a URI by which this document may be referred to.
If primaryAlias attribute is defined and its value is true or 1
then the URI will also be used to define the baseURI for all
relative URIs contained by this document. Otherwise, the
xs:anyURI URI must be an absolute URI and will only
be used as a mean to refer to this document.
</alias> </aliases></docInfo>
[<data>
xs:any <!—At most one definition document goes here>
</data> |<locator>
<documentURI/> ?
xs:any <!—A URI or IRI that points to a definition document goes here>
</locator>
] </document> </definitions> <instances> ? <document> * <docInfo> ? <aliases> ? <alias primaryAlias=”xs:boolean”> +xs:anyURI - a URI by which this document may be referred to.
If primaryAlias attribute is defined and its value is true or 1
then the URI will also be used to define the baseURI for all
relative URIs contained by this document. Otherwise, the
xs:anyURI URI must be an absolute URI and will only
be used as a mean to refer to this document.
</alias> </aliases></docInfo>
[<data>
xs:any<!—At most one instance document goes here>
</data> |<locator>
<documentURI/> ?
xs:any <!—A URI or IRI that points to an instance document goes here>
</locator> ] </document> </instances></model>
A document producer can specify the version of the specification under which
the current document was generated, and with which conformance is claimed, in
the SMLIFVerion
attribute. For example, if this version of SML-IF is used as the basis of a
document, the value of this attribute would be the value "1.1".
The identity element
provides information applications can use to identify and describe the set of
SML documents being interchanged. The baseURI child element defines the
absolute URI to be used by relative URI references in the interchange set .
The schemaComplete
attribute is defined on the definitions element and it is used to
indicate that the schemas constructed from the definition documents in the
interchange set are complete, in the sense
that they contain everything needed
for the full validation of the instance documents, and that the validity of the
instance documents in the interchange set is fully determined by these schemas.
Formally, however, the schemaComplete
attribute does not express any assertion that the schemas so constructed are in
fact complete, or that validation using these schemas will not result in any
errors indicating that some components are missing from the schemas. The only
formal effect of schemaComplete attribute
with a value of true or 1 is to specify precisely
the schemas with which interchange set validation is to be performed.
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 URI 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 being referenced rather than embedded, 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.
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
schemas from multiple schema documents as
part of the interchange set 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/@@@@/@@/sml-if" version="1.0"><identity>
<name>http://www.university.example.org/sml/models/Sample/InterDocReferences</name><baseURI>http://www.university.example.org/Universities/</baseURI>
</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">
<!-- SML 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">
<!-- SML Reference to a course Inside the interchange set -->
<sml:uri>
http://www.university.example.org/Universities/SFU/Courses.xml#xmlns(u=http://www.university.example.org/ns)xpointer(/u:Courses/u:Course[u:Name='MUSIC205'])
</sml:uri>
</EnrolledCourse>
<EnrolledCourse sml:ref="true">
<!-- SML 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 primaryAlias=”true">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><document>
<!-- One of the courses referenced above, with the primary alias containing a relative URI. Both smlif:baseURI and the alias URI will be used to process
the baseURI for relative references contained by this document. -->
<docInfo> </aliases> <alias primaryAlias=”true">/SFU/Courses.xml</alias> </aliases></docInfo>
<data>
<Courses xmlns="http://www.university.example.org/ns">
<Course> <Name>ENG106</Name> </Course> <Course> <Name>MUSIC205</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 equal to the URI in an alias
(see 5.3.1
URI equality), 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 URI reference has a fragment, the
fragment is applied to the referenced document to establish the reference
target(s) according to the corresponding SML reference scheme definition;
otherwise the SML reference target is the root element of the referenced
document.
If the URI is not equal to the URI in any alias,
then the SML-IF document does not contain the corresponding target of the
original URI reference. The consumer may or may not attempt to look for targets
outside of the SML-IF document, depending on the nature of the URI reference.
Referring now to the example SML-IF document above. The URI 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 equal to the URI listed in the alias
accompanying the Courses
document. So, by applying the fragment in the URI reference to the Courses document, we determine that the
reference is to the Course
element whose Name element
has "PHY101" as
its content.
The URI reference:
http://www.university.example.org/Universities/SFU/Courses.xml#xmlns(u=http://www.university.example.org/ns)xpointer(/u:Courses/u:Course[u:Name='MUSIC205'])
, after removing the fragment, becomes
http://www.university.example.org/Universities/SFU/Courses.xml
, which is equivalent with the alias defined on the last instance document
in the interchange set, after the smlif:baseURI
content is applied to the relative URI contained by the document’s primary
alias. So, by applying the fragment in the reference to the Courses document, we determine that the
URI reference is to the Course
element whose Name element
has "MUSIC205" as
its content.
The fragment-free part of the URI 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 equal 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 equal 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 When performing
interchange
set 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.
1. 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.
2.
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).
3. 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 section describes a method to achieve this goal.
An SML-IF document can be:
1. 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.
2. Schema-incomplete - Some required schema documents may not be 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 because making that distinction is not always possible for a
consumer 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:
1.
4 four xsi: attributes (defined by XML Schema)
2. all schema built-in types (xs:anyType and simple types defined in XML Schema Part 2)
3. sml:ref attribute declaration
4. 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>
The goal of SML-IF is to enable the exchange of SML models. However, this interoperability goal is affected by several aspects of SML models.
1. Use of the SML URI Reference Scheme as defined in the SML specification is the only guaranteed way of achieving interoperability for all SML references in the model. Use of any other reference scheme requires that the consumer know about its use in the document and understand how to dereference it.
2.
SML documents can be included by reference using
the locator element and,
therefore, are not directly embedded in the SML-IF document. This can be very
useful, especially when the SML-IF document is large or when the documents are
readily accessible to the consumer. However, the locator element may be ignored by the consumer, may not
resolve, or may resolve to different resources in different contexts. Because
of these uncertainties, interoperability is not guaranteed when documents are
included by reference.
3. The SML-IF document may be schema-incomplete [4.4 Schema Document Bindings]. 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.
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:
1. Minimal Conformance: A minimally conforming SML-IF Document MUST adhere to all SML-IF document requirements as described in the normative sections of this specification.
2. Reference Conformance: A referentially conforming SML-IF Document MUST adhere to all SML-IF document requirements as described in the normative sections of this specification. In addition, each non-null SML reference in the document MUST be an instance of the SML URI Reference Scheme [SML 1.1].
A conforming SML-IF Producer MUST be able to generate a referentially 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
according to the requirements stated in the normative sections of this
specification.
In particular, if a conforming SML-IF Consumer
performs interchange set validation, then that process MUST
be performed as described in this specification.
A conforming
SML-IF Validator is a conforming SML-IF Consumer
that performs interchange set validation as described in this specification.
An SML-IF producer MAY specify the version of the
SML-IF specification with which conformance is declared by including the
version number of the relevant specification as the value of the SMLIFVersion
attribute in the document's model
element. This value MUST be "1.1" for
documents conforming to the SML-IF 1.1 specification. Consumers MUST attempt to process an SML-IF document regardless of
the value of the SMLIFVersion
attribute. Therefore, a consumer of SML-IF document MUST NOT reject the document simply on the basis that it
has a different version of the specification.
Non-normative note: The SMLIFVersion number may be useful when diagnosing
failures enountered while processing SML-IF
documents.
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.
The
definitions and instances documents packaged by anAn
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 SML model and interchange set 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:
1.
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.
2.
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:
1.
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.
2.
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 associated with the SML-IF document.
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:
1.
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.
2.
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.
The smlif:schemaComplete
attribute is defined on the definitions element.
The attribute indicates whether or not all the definition documents required for interchange set validation are included in the interchange set.
If schemaComplete has the
value true or 1, then schemas used for interchange set validation of the interchange set contain only
schema components declared in model definition documents within the interchange
set. If schemaComplete has the
value false or 0, then this specification
does not constrain whether or not definition documents required for interchange set validation of the interchange set are retrieved
from outside the interchange set.
SML-IF uses URI equality extensively to handle references among documents in the interchange set. To determine whether two URIs are equal, 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 equal.
Alias URIs MUST NOT contain fragment components.
All alias
URIs in an SML-IF document MUST
be unique.
smlif:baseURI element is defined as an
optional child of the /model/identify
element. The content of the smlif:baseURI element is
an URI that MUST comply with the “absolute-URI”
production as defined in RFC 3986 ([IETF
RFC 3986]). This implies that the URI does not contain fragment
components. If defined, the content of the smlif:baseURI
element is used to build the [base URI] ([IETF
RFC 3986]) for all relative URIs contained
by the interchange set.
smlif:primaryAlias
attribute is defined on an alias
element and identifies the alias
element whose content is used to build the [base URI] ([IETF
RFC 3986]) for all relative URIs contained
by the definition or instance document identified by this alias. This attribute is of type xs:boolean.
If the smlif:primaryAlias
attribute is defined on an alias
element AE and has the value of true
or 1 and there is no smlif:baseURI
element defined as a child of the /model/identity
element then the content of the AE MUST
comply with the “absolute-URI” production as defined in RFC 3986 ([IETF
RFC 3986]).
If no smlif:primaryAlias
attribute is defined on an alias
element AE or the attribute is defined and has the value of false or 0 then the content of AE MUST
comply with the “absolute-URI” production as defined in RFC 3986 ([IETF
RFC 3986]).
For every model/definitions/document
or /model/instances/document
element in the interchange set let ASE be the /docInfo/aliases
element and let D be the contained schema or instance document. The
following steps MUST be performed when resolving
[base URI] ([IETF
RFC 3986]) information for relative URIs
defined in D:
1. If ASE is defined then:
1. If ASE has no child elements then the [base URI] for any relative URI contained by D is the root element of D.
2.
If more than one alias child element of ASE defines the smlif:primaryAttribute
element with the attribute value being true
or 1 then the SML-IF
document is invalid.
3.
Else if one alias
child element AE defines the smlif:primaryAttribute with the
attribute value being true
or 1 then:
1. If the content of the AE element is an absolute URI then the AE content MUST be used as the [base URI] for all relative URIs contained by D.
2.
Else if no /model/identity/baseURI element defined then the SML-IF
document is invalid.
3.
Else the [base URI] for all relative URIs contained by D MUST
be created by concatenating the /model/identity/baseURI content with the AE content.
4.
Else if no alias
child element defines the smlif:primaryAttribute,
or the smlif:primaryAlias
attribute is defined and has the value false
or 0 then:
1.
If the /model/identity/baseURI element is not defined then the
SML-IF document is invalid.
2.
Else the content of the /model/identity/baseURI
element MUST be used as the [base URI] for all
relative URIs contained by D.
2. Otherwise the [base URI] for any relative URIs contained by D is the root element of D.
When processing an SML-IF document, there are 3 categories of URI references that may need to be resolved:
1.
schemaLocation attributes
on xs:include
and xs:redefine
in schema documents, when they are model definition documents.
2. URI references specified in instances of SML reference schemes that use target-complete identifiers [SML 1.1].
3. URI references specified in instances of SML reference schemes that do not use target-complete identifiers.
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
1. Determine the document D that possibly contains the target:
1.
If
2. Otherwise
1.
If
2. 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 of RFC 3986 ([IETF RFC 3986]); otherwise let U be UR'.
3. If there exists a model document with an alias URI that is equal to U (5.3.1 URI equality), then D is that document; otherwise D has no value.
2. If D has no value, then
1.
If schemaLocation),
then the SML-IF document does not contain the target schema document. Whether
the consumer continues to dereference
2.
Otherwise (R is within category #2, used
in an SML reference)
3. If D is a schema document that is also a model definition document in the interchange set, then
1.
If schemaLocation),
and it does not contain a fragment component, then
2.
Otherwise (
4. If D is a model instance document in the interchange set, then
1.
If schemaLocation),
then it has no target.
2.
If
3.
Otherwise (
5.
Otherwise (D is another kind of document
in the interchange set)
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 equal to the prefix as defined in section 5.3.1 URI equality.
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.
SML-IF Consumers 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.
If an SML-IF consumer chooses to process the schemaBindings
element, then, as part of the interchange set validation, for every schema binding SB
in the model, i.e. every /model/schemaBindings/schemaBinding element, the
SML-IF consumer MUST perform the following steps for
instance document validation.
1.
Compose a schema using all documents specified
under all SB's namespaceBinding
children.
2.
Whenever an import
for a namespace N is encountered, perform the following steps.
1.
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.
2. Otherwise, if there are schema documents in the SML-IF document whose targetNamespace is N, then components from all those schema documents are used.
3.
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.
4. Otherwise, it is implementation-defined whether an SML-IF consumer tries to retrieve components for N from outside the SML-IF document.
3.
Whenever an include or redefine is encountered, the schemaLocation
is used to match aliases of schema documents, as with base SML-IF.
1. If there is a schema document in the SML-IF document matching that alias, then that document is used.
2.
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).
3.
Otherwise, it is implementation-defined whether
an SML-IF consumer tries to resolve include
or redefine to schema
documents outside the SML-IF document.
4.
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.
Whether or not a schemaBindings
element is present or is ignored, SML-IF consumers MUST
process an include
or redefine element as
described in step 3 above.
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.