Copyright © 2008 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This document is a sample wording proposal that has no official standing.
Copyright holders will not be liable for any direct, indirect, special or consequential damages arising out of any use of the software or documentation.
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 **both an implementation-neutral interchange format that preserves the content and interrelationships among the documents** and a constrained form of model validation which respects those interrelationships. This specification defines a standard format called the SML Interchange Format (SML-IF)** and a model validation process called SML-IF model 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.
...
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 **SMLSML-IF 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:
...
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 section describes a method to achieve this goal.
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 - 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:
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.
**In particular, if a conforming SML-IF Consumer performs SML-IF model validation, then that process MUST be performed as described in this specification.
**Note:
**The process of SML-IF model validation follows the definition of SML model validation defined in SML 1.1 but in some cases eliminates some sources of potential variation in the results of model validation, e.g. by specifying precisely the values to be returned when specific URIs are dereferenced or defining exactly which schema components are to included in schemas used to validate instance documents in the model. The constraints imposed on SML-IF model validation are not imposed on other forms of model validation performed on the same models.
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 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:
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.
The schemaComplete attribute on the definitions element
indicates whether or not all the schema documents required for SML-IF model
validation are included in the interchange set of the SML-IF document.
[Version A]
If schemaComplete has the value true,
then a conforming consumer performing SML-IF model validation of the
interchange set MUST NOT retrieve any
schema components from outside the interchange set.
If schemaComplete has the value false,
then whether schema components are retrieved from outside the interchange set
is unconstrained by this specification.
[Version B]
If schemaComplete has the value true,
then the schema used for SML-IF model validation of the
interchange set contains only schema components declared in
model documents within the interchange set.
If schemaComplete has the value false,
then whether schema components are retrieved from outside the interchange set
is unconstrained by this specification.
[Version C]
If schemaComplete has the value true,
then the schema used for SML-IF model validation of the
interchange set contains only schema components declared in
model documents within the interchange set,
and the producer warrants that the schema so constructed is
'complete' in the sense that when it is used to validate the
instance documents in the interchange set, no missing-component errors
(specifically, the errors cvc-elt.1 and
cvc-attribute.1) will occur.
If schemaComplete has the value true,
and validation using the schema constructed according to the rules of
this specification produces missing-component errors, then the
SML-IF document does not conform to this specification.
If schemaComplete has the value false,
then whether schema components are retrieved from outside the interchange set
is unconstrained by this specification.
[End version C]
For fuller details on how the schema used for SML-IF model validation is to be constructed, see 5.5 Schema Document Bindings.
Note:
[Alternative 1]
This note is non-normative.
The expected usage of the schemaComplete attribute is to
indicate that the schema constructed from the definition documents in
the interchange set is complete, in the sense that it contains
everything needed for the full validation of the instance documents,
and the validity of instance documents in the interchange set is fully
determined by the schema.
Formally, however, the schemaComplete attribute does not
express any assertion that the schema so constructed is in fact complete,
or that validation using that schema will not result in any errors
indicating that some components are missing from the schema. The only
formal effect of schemaComplete is to specify precisely the
schema with which SML-IF model validation is to be performed.
Note:
[Alternative 2]
This note is non-normative. Although the absence of required components
is the usual cause for the occurrences of the missing-component errors
cvc-elt.1 and cvc-attribute.1, it is possible
for other problems, such as misspelled element names, to produce the
same results. The problem is analogous to that of missing variable
declarations and misspelled variable references in programming languages.
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,
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** performed as part of
SML-IF model 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.
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.
...