1. Introduction(Non-Normative)
As defined in the Service Modeling Language, Version 1.1 (SML)Specification [SML 1.1] an SMLmodel is a collection of XML documents that may be used to describecomplex services and systems such as a set of IT resources,services and their interrelations.
In every SML model there are two distinguished subsets of themodel's documents, the definition documents and the instancedocuments. The model's definition documents describe the abstractstructure of the model, and provide much of the information a modelvalidator needs to decide whether the model, as a whole, is valid.The model's instance documents describe or support the descriptionof the individual resources that the model portrays.
The SML Specification identifies two categories of modeldefinition documents that participate in SML model validation:Schema documents and rule documents. Schema documents in a modelare XML documents that conform to the [SML1.1] defined extensions to XML Schema [XML Schema Structures,XMLSchema Datatypes]. Rule documents in a model include XMLdocuments that conform to the [SML1.1] defined extensions of Schematron [ISO/IEC 19757-3].
To ensure accurate and convenient interchange of the documentsthat make up an SML model, it is useful to define both animplementation-neutral interchange format that preserves thecontent and interrelationships among the documents and aconstrained form of SML model validation. For this purpose, thisspecification defines a standard format called the SML InterchangeFormat (SML-IF) and a process called interchange modelvalidation.
The specification consists of two parts. The first part is aninformal description of SML-IF to set the context. This is followedby SML-IF's normative definition.
4.Informal Description (Non-Normative)
To represent an SML model in a standard way for interchange, thefollowing topics need to be addressed.
Packaging: The collection of XML documents that make up amodel to be interchanged need to be gathered together. In doing so,the model definition and model instance documents need to bedistinguished from one another since they play distinct roles inthe model.
Explicit references: The documents to be interchanged mayexplicitly refer to one another and to documents that are notpackaged with the documents being interchanged. [SML 1.1] SML references among SML model instancedocuments are an obvious example. Less obvious are such referencesas certainschemaLocation attributes in schemadocuments andxsi:schemaLocation attributes ininstance documents. Section4.4Schema Bindings defines howschemaLocation isprocessed in these cases.
Rule bindings and schema bindings: [SML 1.1] permits models in which rule documentsapply to all, none, or subsets of the model's documents. SML-IFspecifies how to describe which rule documents apply to which ofthe model's documents.
Model validation: The process of SML model validationdefined in [SML 1.1] containspoints of variability that, left unconstrained, would make itdifficult for SML-IF to ensure interoperability of independentimplementations in any practical way. Many of these sources ofvariability are inherited from other specifications that SML uses,e.g. URI comparison RFC 3986 ([IETF RFC3986]) and the source of Schema components([XML Schema Structures]) used tovalidate model instance documents. SML-IF constrains these pointsof variability, with the goal of ensuring interoperability whenspecific conditions are met and of increasing the likelihood ofinteroperability in other cases. The enforcement of theseadditional constraints on SML model validation occurs during theprocess ofinterchangemodel validation.
4.1 Packaging
An SML-IF document packages a collection of SML model documentsto be interchanged as a single XML document. All SML-IF documentsconform to the XML Schema defined in the normative part of thisspecification.
Informally, the structure of SML-IF documents, using thepseudo-schema notation from WSDL 2.0 [WSDL2.0 Core Language] is as follows:
<?xml version="1.0" encoding="UTF-8"?><model xmlns="http://www.w3.org/ns/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" schemaComplete="xs:boolean"> <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> <baseURI> xs:anyURI <!-- Base URI for relative references defined in the interchange model; must be an absolute reference --> </baseURI> ? <description sml:locid="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> <noSchemaBinding> ? <documentAlias/> * </noSchemaBinding> </schemaBindings> <definitions> ? <document> * <docInfo> ? <baseURI> ? xs:anyURI <!-- If a document has a baseURI, then this will be used to form the base URI for all relative URIs subject to SML URI processing contained by that document. --> </baseURI> <aliases> ? <alias> * xs:anyURI <!-- A URI by which SML references from other documents may refer to this document. --> </alias> </aliases> </docInfo> [ <data> xs:any <!-- At most one definition document goes here --> </data> | <base64Data> xs:any <!-- At most one base64 encoded definition document goes here --> </base64Data> | <locator> <documentURI/> ? xs:any <!-- A URI or IRI that points to a definition document goes here --> </locator> ] </document> </definitions> <instances> ? <document> * <docInfo> ? <baseURI> ? xs:anyURI <!-- If a document has a baseURI, then this will be used to form the base URI for all relative URIs subject to SML URI processing contained by that document. --> </baseURI> <aliases> ? <alias> * xs:anyURI <!-- A URI by which SML references from other documents may refer to this document. --> </alias> </aliases> </docInfo> [ <data> xs:any<!-- At most one instance document goes here --> </data> | <base64Data> xs:any <!-- At most one base64 encoded instance document goes here --> </base64Data> | <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 specificationunder which the current document was generated, and with whichconformance is claimed, in theSMLIFVerion attribute.For example, if this version of SML-IF is used as the basis of adocument, the value of this attribute would be the value "1.1".
Theidentity element provides informationapplications can use to identify and describe the set of SMLdocuments being interchanged. ThebaseURI childelement is one way to specify a base URI to be used by relative URIreferences in theinterchangemodel. Another way to specify a base URI is to use thedocument/docInfo/baseURI element. [5.3.2 Base URIs]
TheSMLIFVersion attribute is defined on themodel element and may be useful when diagnosingfailures encountered while processing SML-IF documents. Forexample, if a document asserts conformance with version 1.1 of theSML-IF specification and a human can see that it is not in factconformant, then it is likely that the problem occurred during theproduction of the document. If the same document appears to humansto be conformant, then the focus of diagnosis might shift towardtheSML-IF consumer and itsinvocation parameters.
TheschemaComplete attribute is defined on themodel element and is used to indicate that the schemasconstructed from the definition documents in the interchange modelare complete, in the sense that the validity of the interchangedSML model is fully determined by these schemas. Formally, however,theschemaComplete attribute does not express anyassertion that the schemas so constructed are in fact complete, orthatinterchange modelvalidation using these schemas will not result in any errorsindicating that some components are missing from the schemas. Theonly formal effect ofschemaComplete attribute with avalue oftrue or1 is to specifyprecisely the schemas with which interchange model validation is tobe performed.
The optionalruleBindings element is used tocontain information that associates rule documents with thedocuments they apply to. See4.3 RuleBindings for further details.
Every document in theinterchange model appears as content of adocument element in either thedefinitions or theinstances element,depending on whether the document in question is a model definitionor a model instance document. There can be at most one embeddeddocument contained by adocument/data element. Bothdefinitions andinstances are optional.So, for example, if there are no model definition documents beingpackaged, thedefinitions element must be omitted.
The first child of eachdocument is typically adocInfo element that contains abaseURIelement and a list ofalias elements. ThebaseURI element can be used to specify a base URI forrelative references in the document. Defining base URIs isspecified in5.3.2 Base URIs. Thecontent of eachalias element is a URI with nofragment component (i.e., one with no "#" in it). Each of thealias elements serves as a name that other documentscan use to refer to this document. Examples of how aliases are usedto handle URI references are given in4.2 URI References.
A document in the interchange model can be represented in eitherof two ways, by embedding its content, or by providing a referenceto it. Which is being used is indicated by the child of thedocument element. A document can be embedded as-is orin a base64 encoded format. In the former case, adataelement is used to contain the actual content of the documentwhereas abase64Data element is used for the latter.The base64 format is typically used for, but is not restricted to,documents with DTD. If the document is being referenced rather thanembedded, alocator element is used to contain thereference. The content of alocator can be adocumentURI element defined by SML-IF or anything elseunderstood by theSML-IFconsumer.
Although it is not fully shown in the pseudo-schema above, theSML-IF schema has an "open content model." To provideextensibility, essentially every element in it can containadditional content and/or attributes from other XML namespaces.
4.2 URIReferences
When processing the SML model packaged inside an SML-IFdocument, certain URI references (as defined in RFC 3986[IETF RFC 3986]) may need to beprocessed to find their corresponding target. For example, in orderto assess SML validity of the interchanged model, SML referencesusing the SML URI Reference Scheme [SML1.1] need to be resolved. In addition, in order toassemble schemas from multiple schema documents as part of theinterchange model validity assessment, the schemaLocation attributeon anxs:include element needs to be processed tolocate the schema document.
To see how these URI references are handled, consider thefollowing SML-IF document:
<?xml version="1.0" encoding="UTF-8"?><model xmlns="http://www.w3.org/ns/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" xmlns:u="http://www.university.example.org/ns"> <ID>1000</ID> <Name>John Doe</Name> <EnrolledCourses> <EnrolledCourse sml:ref="true"> <!-- SML Reference to a course INside the interchange model --> <sml:uri> http://www.university.example.org/Universities/MIT/Courses.xml#smlxpath1(/u:Courses/u:Course[u:Name='PHY101']) </sml:uri> </EnrolledCourse> <EnrolledCourse sml:ref="true"> <!-- SML Reference to a course INside the interchange model --> <sml:uri> http://www.university.example.org/Universities/SFU/Courses.xml#smlxpath1(/u:Courses/u:Course[u:Name='MUSIC205']) </sml:uri> </EnrolledCourse> <EnrolledCourse sml:ref="true"> <!-- SML Reference to a course OUTside the interchange model --> <sml:uri> http://www.university.example.org/Universities/Capella/Courses.xml#smlxpath1(/u:Courses/u:Course[u:Name='LIT103']) </sml:uri> </EnrolledCourse> </EnrolledCourses> </Student> </data> </document> <document> <!-- The following alias matches the first course 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> <document> <docInfo> <baseURI>SFU/Courses.xml</baseURI> <!-- The following alias matches the second course referenced above (after being converted to an absolute URI) --> </aliases> <alias>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>
When not packaged in an SML-IF document, certain URI references(e.g. values ofsml:uri elements or certainschemaLocation attributes) are dereferenced to findtheir corresponding document. When these references are packaged inan SML-IF document, consumers of the SML-IF document need to firstexamine whether the target document or element is packaged in thesame SML-IF document. To determine this, the fragment component, ifany, is temporarily ignored to form a URI. This URI is thencompared against thealias URIs of packaged modeldocuments.
If the URI is equal to the URI in analias element(see5.3.1 URI equality), theSML-IF consumer will notattempt to look for targets of this URI outside of the SML-IFdocument, although there may exist a document retrievable at thisURI. If the URI is not equal to the URI in anyaliaselement, then the SML-IF document does not contain thecorresponding target of the original URI reference. The consumermay or may not attempt to look for targets outside of the SML-IFdocument, depending on the nature of the URI reference. Formalrules about how URI references are processed are defined in section5.3.4 URI ReferenceProcessing.
Several examples of resolving references can be seen in theexample SML-IF document shown above, illustrating the use of bothrelative and absolute alias URI values. In the first example, areference with an absolute URI, the following SML reference, mustfirst be separated into its document URI and fragmentcomponents:
http://www.university.example.org/Universities/MIT/Courses.xml#smlxpath1(/u:Courses/u:Course[u:Name='PHY101'])
After removing the fragment, the document portion of thereference is:
http://www.university.example.org/Universities/MIT/Courses.xml
This document URI is equal to the URI listed in analias accompanying theCourses document.So, by applying the fragment in the URI reference to theCourses document, we determine that the reference isto theCourse element whoseName elementhas"PHY101" as its content.
The second example reference, using a relative URI, is processedsimilarly. The full reference is:
http://www.university.example.org/Universities/SFU/Courses.xml#smlxpath1(/u:Courses/u:Course[u:Name='MUSIC205'])
After removing the fragment, the document portion of thereference is:
http://www.university.example.org/Universities/SFU/Courses.xml
This URI is equal to analias defined on the lastinstance document in the interchange model, after themodel/identity/baseURI content is applied to therelative URI contained by the document’saliaselement. So, by applying the fragment in the reference to theCourses document, we determine that the reference isto theCourse element whoseName elementhas"MUSIC205" as its content.
The third example, showing an unresolved reference, is processedsimilarly. The full reference is:
http://www.university.example.org/Universities/Capella/Courses.xml#smlxpath1(/u:Courses/u:Course[u:Name='LIT103'])
After removing the fragment, the document portion of thereference is:
http://www.university.example.org/Universities/Capella/Courses.xml
This document URI is not equal to the URI in anyalias element. This means that it is an unresolved SMLreference.
The URI:
http://www.university.example.org/university/enrollmodel.xsd
(value of theschemaLocation attribute on theinclude element) is not equal to anyalias. TheSML-IFconsumer may or may not attempt to locate a schema documentusing this URI reference.
4.3 RuleBindings
[SML 1.1] uses Schematronpatterns embedded in SML schemas and in separate explicitly boundrule documents to express constraints that cannot be expressed inXML Schemas. Schematron patterns embedded in SML Schema documentsall have well defined targets. [SML1.1] permits models in which rule documents apply toall, none, or subsets of the model's documents. SML-IF uses thelist ofruleBinding elements contained in the optionalruleBindings element to associate rule documents withthe documents in the interchange model to which they apply. EachruleBinding associates the documents having an aliasbeginning with the URI prefix given in thedocumentAlias with the rule documents having an aliasbeginning with the prefix given in theruleAlias. So,for example, theruleBinding:
<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 theinterchange model. It does not specify rule bindings that apply todocuments not in the interchange model. That said, it is often thecase that the intent of transferring an SML-IF document is torelate its contents with other SML documents not in the interchangemodel. For example, the intent might be to merge the interchangemodel with an existing SML model. In such cases the context of usemay choose to extend the definition ofruleBinding tobind documents not in the interchange model. For example, if theinterchange model is merged into an existing model, the mergeprocess might choose to extend the definition ofruleBinding elements to bind rule documents in theinterchange model to documents in the merged model that weren'tincluded in the interchange model.
4.4 SchemaBindings
Schema documents can be connected with other schema documentsusing composition features provided by XML Schema. This includesxs:include,xs:redefine, andxs:import. A schema document's validity may depend onother schema documents it includes/redefines/imports, or even otherschema documents that include/redefine/import it. When performinginterchange modelvalidation over the SML model packaged in an SML-IF instance,an SML-IF consumer must draw associations between XML Schemadefinition documents and instance documents, both to completelyvalidate XML Schema documents themselves and to establish theschema-validity of the instance documents.
The XML Schema specification provides more flexibility inconstructing the schema used for assessment than is appropriate forthe semantics defined by SML and SML-IF forinterchange model validation.
It allows XML Schema processors latitude in terms of locatingschema documents (resolving namespace and schema locationattributes) and composing schema documents together to form asingle schema.
Schema location attributes can be ignored in some cases(xsi:schemaLocation in instance documents andschemaLocation attribute onxs:import)and allowed to "fail to resolve" in others(schemaLocation attribute onxs:includeandxs:import).
Multiple imports of the same namespace allow all but the firstone to be ignored.
As a result, SML-IF cannot guarantee general caseinteroperability based only on XML Schema and, therefore, needs tospecify how to determine such associations. This section describesa method to achieve this goal.
An SML-IF document can be:
Schema-complete - All schema documents are included inthe SML-IF document, either as an5.2.1 Embedded Documents or as5.2.2 ReferencedDocuments.
Schema-incomplete - Some required schema documents maynot be included in the SML-IF document, either as an embeddeddocument or a referenced document.
It is necessary for an SML-IF producer to declarativelydistinguish between these two cases because making that distinctionis not always possible for anSML-IF consumer based on the content alone.SML-IF uses theschemaComplete attribute on themodel element to indicate whether this SML-IF documentincludes all necessary schema definition documents. When thisattribute is specified with a value of "true", then the schemavalidity of the schema definition documents and instance documentsdepend only on built-in components or components from definitiondocuments included in the SML-IF document. Built-in componentsinclude:
four xsi: attributes (defined by XML Schema)
all schema built-in types (xs:anyType and simple types definedin XML Schema Part 2)
sml:ref attribute declaration
sml:uri element declaration
An SML model represented by a schema-incomplete SML-IF documentis not necessarily invalid. However, SML-IF cannot guaranteeinteroperability for a schema-incomplete SML-IF document.
SML-IF uses a list ofschemaBinding elementscontained in the optionalschemaBindings element toassociate a namespace with a set of schema documents in theinterchange model and the instance documents that should bevalidated against this set of schema documents. EachnamespaceBinding child of aschemaBindingelement associates the namespace specified in itsnamespace attribute with the schema documents whosealiases are specified in itsaliases attribute. Inaddition, the instance documents that are to be assessed againstthis set of schemas are specified in thedocumentAliaschild element of the sameschemaBinding 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> <!-- schema documents for xsd1-a, xsd1-b, xsd2-v1, xsd2-v2 --></definitions>
There are cases where many instance documents use the sameschema. In this case, it is desirable to have a default schemabinding rather than specifying aschemaBinding thatlists all these instance documents. ThedefaultSchemacan be used to cover instance documents not included in anyotherschemaBinding 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>
There may be cases where an instance document should not bebound to any schema, including the default schema. ThenoSchemaBinding element can be used in this case tocover such instance documents as in the following example.
<schemaBindings> <!-- The "noSchemaBinding" element contains the aliases for all instance documents *not* bound to any schema. --> <noSchemaBinding> <documentAlias>doc-a</documentAlias> <documentAlias>doc-b</documentAlias> </noSchemaBinding></schemaBindings>
4.5Interoperability of SML Models
The goal of SML-IF is to enable the exchange of SML models.However, this interoperability goal is affected by several aspectsof SML models.
Use of the SML URI Reference Scheme as defined in the SMLspecification is the only guaranteed way of achievinginteroperability for all SML references in the model. Use of anyother reference scheme requires that theSML-IF consumer know about its use in thedocument and understand how to dereference it.
SML documents can be included by reference using thelocator element and, therefore, are not directlyembedded in the SML-IF document. This can be very useful,especially when the SML-IF document is large or when the documentsare readily accessible to the consumer. However, thelocator element may be ignored by the consumer, maynot resolve, or may resolve to different resources in differentcontexts. Because of these uncertainties, interoperability is notguaranteed when documents are included by reference.
The SML-IF document may be schema-incomplete [4.4 Schema Bindings]. An SML modelrepresented by a schema-incomplete SML-IF document is notnecessarily invalid. However, SML-IF cannot guaranteeinteroperability for a schema-incomplete SML-IF document.
The SML-IF document may use reference schemes that do not usetarget-complete identifiers. In addition to the requirementsimposed by SML on reference scheme definitions, SML-IF imposesadditional requirements on references schemes that do not usetarget-complete identifiers in order to make them useful in thecontext of SML-IF [5.3.4 URI ReferenceProcessing].
The presence of relative references subject to SML-IF URIprocessing introduces the necessity to transform them into absolutereferences [5.3.4 URI ReferenceProcessing]. SML-IF provides two alternative mechanisms[5.3.2 Base URIs] for doing so, oneof which is deprecated. SML-IF producers can construct SML-IFdocuments that use either only absolute URIs or both base URImechanisms in order to achieve interoperability with the maximumnumber of consumers.