Version 1.0, 28 February 2007
John Arwe, IBM
Jordan Boucher, Sun
Pratul Dublish, Microsoft
Zulah Eckert, BEA
Dave Ehnebuske, IBM
Jon Hass, Dell
Steve Jerman, Cisco
Heather Kreger, IBM
Vincent Kowalski, BMC
Milan Milenkovic, Intel
Bryan Murray, HP
Phil Prasek, HP
Junaid Saiyed, EMC
Harm Sluiman, IBM
Bassam Tabbara, Microsoft
Vijay Tewari, Intel
William Vambenepe, HP
Marv Waschke, CA
Andrea Westerinen, Microsoft
Permission to copy and display the Service Modeling Language Interchange Format (SML-IF) Specification, in any medium without fee or royalty is hereby granted, provided that you include the following on ALL copies of the SML-IF Specification, or portions thereof, that you make:
BEA, BMC, CA, Cisco, Dell, EMC, HP, IBM, Intel, Microsoft, and Sun (collectively, the “Authors”) each agree to grant you a royalty-free license, under reasonable, non-discriminatory terms and conditions to their respective patents that they deem necessary to implement the Service Modeling Language Specification.
THE SML-IF SPECIFICATION IS PROVIDED "AS IS," AND THE AUTHORS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS OF THE SML INTERFACE FORMAT SPECIFICATION ARE SUITABLE FOR ANY PURPOSE; NOR THAT THE IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS.
THE AUTHORS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF OR RELATING TO ANY USE OR DISTRIBUTION OF THE SML INTERCHANGE FORMAT SPECIFICATION.
The name and trademarks of the Authors may NOT be used in any manner, including advertising or publicity pertaining to the SML-IF Specification or its contents without specific, written prior permission. Title to copyright in the SML-IF Specification will at all times remain with the Authors.
No other rights are granted by implication, estoppel or otherwise.
This specification defines the interchange format for SML models.
This specification is a draft in progress. It is being published to solicit feedback. A feedback agreement is required before the working group can accept feedback. Please contact sml-feedback@external.cisco.com for details.
At some future date, the contents may be published under another name or under several new specifications, as shall be agreed by the authors and their respective corporations at that time.
3. SML-IF Normative Definition
3.3.2 Definition of inter-document references in SML-IF
3.3.3 SML reference schemes that are not SML-IF inter-document references
3.3.5 Presence of the baseURI element
3.3.6 Resolving inter-document references
Appendix A – [Normative] SML-IF Schema
Appendix B – Normative References
As defined in the Service Modeling Language (SML) Specification [1] an SML model is a collection of XML documents that may be used to describe such things as a set of IT resources, services and their interrelations.
In every SML model there is a distinguished subset of the documents that comprise it, called the model definition documents. A 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 other documents in the model, called its model instance documents, describe or support the description of the individual resources the model portrays. Broadly speaking, an SML model is a graph of nodes connected to one another by arcs. The nodes are formed by model instance documents; explicit inter-document references form its arcs.
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-defined subset and extensions to XML Schema 1.0 [2, 3]. Rule documents in a model are XML documents that conform to the SML-defined subset and extensions of Schematron[4].
To ensure accurate and convenient interchange of the documents that make up an SML model or a portion of an SML model, it is useful to define an implementation-neutral interchange format that preserves the content and interrelationships among the documents. This specification defines a standard format called the SML Interchange Format (SML-IF) that does that.
The specification consists of two parts: The first part is an informal description of SML-IF to set the context. This is followed in part two by SML-IF’s normative definition.
To represent an SML model in a standard way for interchange, three topics need to be addressed.
Packaging: The collection of XML documents that make up a model (or model portion) to be interchanged need to be gathered together. In doing so, the model definition and model instance documents need to be distinguished from one another since they play distinct roles in the model.
Since documents may have been signed using XML Signature [5] or have had cryptographic digests made of them for other purposes, documents exchanged using SML-IF must be invariant with respect to XML Canonicalization. [6]
Explicit inter-document 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 uses such references for many purposes, and
permits many different addressing mechanisms. The arcs in SML
models are an obvious example. Less obvious are such references as
xsi:schemaLocation. The SML-IF specifies a uniform
mechanism for unambiguously resolving references among the
documents being interchanged.
Binding of rule documents to the documents to which they apply: SML 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.
The SML-IF packages the collection of SML documents to be interchanged as a single XML document. All SML-IF documents conform to the XML Schema defined in the normative part of this specification.
Informally, the structure of SML-IF documents, using the pseudoschema notation from WSDL 2.0 [11] is as follows:
<?xml version="1.0"
encoding="UTF-8"?>
<model xmlns="http://schemas.serviceml.org/smlif/2007/02"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<identity>
<name>
xs:anyURI Namespace identifying the
model
</name>
<version> ?
xs:token <!—The version of
this model. E.g., 1.2 or 0.3>
</version>
<displayName smlerr:localizationid=
”xs:anyURI URI identifying the translation
resource for the display name” ?> ?
xs:string Descriptive name of model
intended for display
<displayName/>
<baseURI>xs:anyURI</baseURI> ?
<description smlerr:localizationid=
”xs:anyURI URI identifying the translation
resource for the description” ?> ?
xs:string Textual description of
model for human consumption
<description/>
</identity>
<ruleBindings> ?
<ruleBinding> *
<documentAlias=”xs:anyURI”/> ?
<ruleAlias=”xs:anyURI”/>
</ruleBinding>
</ruleBindings>
<definitions> ?
<document> *
<docInfo> ?
<aliases> ?
<alias> *
xs:anyURI A URI by which this document may be referred to
</alias>
</aliases>
</docInfo>
[
<data>
xs:any <!—A
definition document goes here>
</data>
|
<locator>
<documentURI/>
?
xs:any <!—A
reference to a definition document goes here>
</locator>
]
</document>
</definitions>
<instances> ?
<document> *
<docInfo> ?
<aliases> ?
<alias> +
xs:anyURI A URI by which this document may be referred to
</alias>
</aliases>
</docInfo>
[
<data>
xs:any<!—An
instance document goes here>
</data>
|
<locator>
<documentURI/>
?
xs:any <!—A
reference to an instance document goes here>
</locator>
]
</document>
</instances>
</model>
The identity element provides
information applications can use to identify and describe the set
of SML documents being interchanged. The baseURI
element defines the absolute URI that inter-document references
using relative URIs are based on.
The optional ruleBindings element
is used to contain information that associates Schematron Rule
documents with the documents they apply to. See section 2.3 for
further details.
The set of SML documents that are interchanged
in a 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. 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 components (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 resolve inter-document references are given below.
A document in the interchange set can be
represented in either of two ways, by embedding its content, or by
providing a reference to it. Which is being used is indicated by
the next child of the document element. If the
document is to be embedded, a data element is used to
contain the actual content of the document. If the document is to
be referred to, a locator element is used to contain
the reference. Syntactically, the content of a locator
can be a documentURI element defined by SML-IF or
anything else understood by the consumer. Typically it is a URI, an
XLink [12], or a Web Services Addressing endpoint reference
[9].
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.
Explicit inter-document references can appear
in SML documents as elements. For example, model arcs are
represented by elements marked with the global attribute
sml:ref=”true”. Inter-document references
can also appear as attributes. For example, an
xsi:schemaLocation attribute provides a hint about
where to find a relevant schema document.
To see how inter-document references are handled, consider the following SML-IF document:
<?xml version="1.0"
encoding="UTF-8"?>
<model xmlns="http://schemas.serviceml.org/smlif/2007/02"
xmlns:sml=”http://schemas.serviceml.org/sml/2007/02”
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
version="1.0">
<identity>
<name>http://example.com/sml/models/Sample/InterDocReferences</name>
<baseURI>http://example.com/sml/models/</baseURI>
</identity>
<instances>
<document>
<data>
<Student
xmlns="urn:university"
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xsi:schemaLocation=”urn:university
http:example.com/university/enrollmodel.xsd”>
<ID>1000</ID>
<Name>John Doe</Name>
<EnrolledCourses>
<EnrolledCourse sml:ref=”true”>
<sml:uri>/Universities/MIT/Courses.xml#xmlns(u=urn:university)
xpointer(/u:Courses/u:Course[u:Name=’PHY101’])
</sml:uri>
</EnrolledCourse>
<EnrolledCourse sml:ref=”true”>
<sml:uri>
/Universities/Capella/Courses.xml#xmlns(u=urn:university)
xpointer(/u:Courses/u:Course[u:Name=’LIT103’])
</sml:uri>
</EnrolledCourse>
</EnrolledCourses>
</Student>
</data>
</document>
<document>
<docInfo>
<aliases>
<alias>/Universities/MIT/Courses.xml</alias>
</aliases>
</docInfo>
<data>
<Courses
xmlns="urn:university">
<Course>
<Name>PHY101</Name>
</Course>
<Course>
<Name>MAT200</Name>
</Course>
</Courses>
</data>
</document>
</instances>
</model>
SML-IF uses equivalence of URIs to resolve
inter-document references among documents being interchanged. In
deciding equivalence of URIs, SML-IF adopts the definition in RFC
3986. [7]. See section 6, “Equivalence,” and section 5
“Reference Resolution” in particular. For the algorithm
in section 5, the “base URI” is the one specified in
the baseURI in the identity element.
With the exceptions explained in the normative
part of this specification, content whose type is
anyURI or a type derived from anyURI and
is contained in a document in the interchange is considered to be
an inter-document reference.
If the URI in such a reference is equivalent
to the URI in an alias, the reference is to the
document with that alias, irrespective of any document that may be
retrievable at this URI. If the reference has a fragment, the
fragment is applied to the referred-to document to establish which
element the reference points to.
If the element in a reference is not
equivalent to the URI in any alias, the reference is
to some (element of a) document not included in the interchange
set. Such references are called unresolved references.
SML-IF specifies how sets of SML documents are interchanged. If and how an SML-IF document’s interchange set relates to a complete (i.e., “validatible”) model is context dependent and is not a part of this specification. One common relationship is that the interchange set constitutes a complete SML model. In such a case, the documents that unresolved references refer to are simply unavailable to the validation process. When SML-IF documents are used in other contexts, such as when they are the content of Web services requests or responses, the set of documents constituting a complete model may include more or fewer documents than those in the interchange set, and the conventions with respect to unresolved references may be different. For example, the convention may specify how to (attempt to) resolve such references.
The absolute URI form of every alias in an interchange, like all absolute URIs, contains an “authority” component. A reasonable interpretation of SML-IF aliases is that the SML-IF document containing them is asserting that the content marked with a given alias is a true copy of the content identified by that URI and issued by the authority in the alias URI. Since this may or may not be true, consumers need to be cautious with this interpretation.
Referring now to the example SML-IF document, above. The reference:
/Universities/MIT/Courses.xml#xmlns(u=urn:university)
xpointer(/u:Courses/u:Course[u:Name=’PHY101’])
is equivalent to the URI listed in the
alias accompanying the Courses document.
(I.e., “/Universities/MIT/Courses.xml”).
So, by applying the fragment in the reference to the
Courses document, we determine that the reference is
to the Course element whose Name element
has “PHY101” as its content.
The reference:
/Universities/Capella/Courses.xml#xmlns(u=urn:university)
xpointer(/u:Courses/u:Course[u:Name=’LIT103’])
is not equivalent to the URI in any
alias. This means that it is an unresolved reference.
Since the reference is written as a relative reference, URI coming
out of the reference resolution algorithm:
http://example.com/Universities/Capella/Courses.xml
#xmlns(u=urn:university)
xpointer(/u:Courses/u:Course[u:Name=’LIT103’])
is a hint for where to find the document.
The URI:
http:example.com/university/enrollmodel.xsd
(in the content of xsi:schemaLocation for the
Student document) isn’t equivalent to any alias.
Since it is written as an absolute URI, the reference is to the
document the URL locates. The same is true for all of the absolute
URIs in the documents being interchanged:
urn:university
and
http://www.w3.org/2001/XMLSchema-instance
The other URIs in the example SML-IF document are not parts of the SML model being interchanged, so they are not SML inter-document references.
SML 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 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 theruleAlias. So,
for example, the ruleBinding:
<ruleBinding/>
<documentAlias=“http://example.com/sml/infrastructure/”/>
<ruleAlias=“http://example.com/sml/infrastructurerules/”/>
</ruleBinding/>
Would associate documents that have the aliases such as:
http://example.com/sml/infrastructure/server427.xml
and
http://example.com/sml/infrastructure/switch6E.xml
with rule documents that have aliases such as:
http://example.com/sml/infrastructurerules/assetistracked.sch
and
http://example.com/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.
This section normatively defines the Service Modeling Language Interchange Format (SML-IF). It is not primarily intended as motivational or introductory material. For such material, please see the non-normative informal description, above. Instead, this section is intended to concisely define the requirements SML-IF documents must adhere to and to define the how inter-document references contained in them are to be interpreted by consumers of SML-IF documents.
A producer is any process that constructs an SML-IF document. A producer creates SML-IF document for the purpose of conveying an SML model to one or more consumers. A consumer is any process that interprets the content of an SML-IF document for the purpose of understanding the model it contains. Using an SML-IF document to achieve the goal of accurately conveying an SML model from producer to consumer is called “interchanging the SML model.”
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 [10].
Producers and consumers of SML-IF documents are required to behave as described; otherwise they are in error.
The purpose of SML-IF is to package the set of documents representing an SML model to be interchanged into a single XML document in a standard way. The set of documents to be interchanged is called the SML-IF document’s interchange set. The documents in the interchange set constitute the SML model being interchanged.
As defined by SML [1], model validity is with respect to some identifiable set of documents. That is, every specific collection of documents either forms a valid model or it does not. But SML-IF is about the interchange of models, not about their validation. Specifically, there is no requirement that the interchange set form a valid SML model. Various uses of SML-IF may well define requirements with respect to model validity and the interchange set, but SML-IF itself does not.
An SML-IF document must conform to XML 1.0 (Second Edition) [8] and must be encoded either in UTF-8 or in UTF-16. Additionally, it must be valid under the XML Schema given in Appendix A, below.
Each document in the interchange set is
represented in SML-IF as the content of a separate
document element. There are two ways to do this. The
octet stream representing the document to be included may be
physically embedded in the SML-IF document. Alternatively, a
reference to the document to be included may be placed in the
SML-IF document.
If a document is to be physically embedded in the SML-IF document, the octet stream representing it must first be processed as follows:
The resulting octet stream is then embedded as
the content of the data child of the corresponding
document element in the SML-IF document.
If on the other hand a document is to be
referred to, a reference to it is placed in the
locator child of the corresponding
document element. SML-IF specifies one way such
references may be constructed, the documentURI
element, however any representation the producer and consumer agree
on may be used. An SML-IF consumer processing the URI in a
documentURI element may obtain the referred-to
document by dereferencing the URI using the default retrieval
action for the URI’s scheme. Producers should
anticipate this usage. Typical alternative representations
include URIs, XLinks [12], and WS Addressing [9] endpoint
references. Since documents referred to using the
locator mechanism are members of the interchange set,
a consumer cannot fully understand the model being interchanged if
it cannot obtain the referred-to documents.
Each definition document in the interchange
set appears as a child of a document element that is a
child of the definitions element of the SML-IF
document. The order of the document children is not
significant.
Similarly, each model instance document in the
interchange set appears as a child of a document
element that is a child of the instances element of
the SML-IF document. Here too, the order of the
document children is not significant.
SML-IF uses URI equivalence extensively to
resolve references among documents in the interchange set. To
determine whether two URIs are equivalent, consumers must
use the definition of URI equivalence given by RFC 3986 [7]. The
algorithm given there requires that a “base URI” be
established whenever a relative URI is tested for equivalence with
another URI. In SML-IF, the base URI is defined to be the absolute
URI given in the baseURI child of the
identity element. As defined below, the
baseURI element will always be present when relative
URIs must be tested for equivalence.
Definition: In the context of SML-IF,
an inter-document reference is any content in a document in the
interchange set whose type is xs:anyURI or a type
derived from xs:anyURI and whose context in the
document implies that the URI can (given the right permissions and
connectivity) be dereferenced using the default retrieval action
for the URI’s scheme.
Note: this definition WILL change to not require PSVI once the schema binding issue is resolved. See issue 9.
For example, an
xsi:schemaLocation attribute is defined to be of type
list of xs:anyURI. These come in pairs, one for the
namespace name, and one for a hint as to the location of a schema
document defining names for that namespace name. This makes
the “hint” URIs in xsi:schemaLocation
attributes inter-document references in the context of SML-IF.
Similarly, an sml:uri element
contained in an element marked with
sml:ref=”true” is an inter-document
reference because its content is of type xs:anyURI and
the definition of sml:uri is that the referred-to
document can be obtained by dereferencing the URI using the default
retrieval action. In contrast, the wsa:address in a
Web Services Addressing [9] endpoint reference is not an
inter-document reference in the context of an SML-IF document. This
is because, although a wsa:address is defined to be of
type anyURI, the action needed to dereference the URI
is not the default retrieval action for the scheme of the URI.
Instead, the action required is defined by protocol binding used to
interact with the endpoint.
Consumers must interpret
xsi:schemaLocation hints [1] and
sml:uri content used as SML reference schemes as
inter-document references. Consumers must not interpret
wsa:address content as inter-document references.
SML [1] defines two reference schemes, the
sml:uri scheme and the EPR scheme. It also permits new
schemes to be created without limit. Schemes that do not use URIs
or whose use of URIs does not imply that the URIs may be
dereferenced for retrieval using the default action (e.g., for the
HTTP scheme, the GET method) are not inter-document references in
the context of SML-IF. Three consequences flow from this.
First, to successfully interchange documents
using such schemes, the sml:ref elements containing
them must also contain an sml:ref scheme that is an
inter-document reference in the SML-IF context. For example, an
sml:ref that contains an EPR scheme reference (which
is not an inter-document reference in SML-IF) could also contain an
sml:uri scheme reference (which is).
Second, the producer of the SML-IF document
and the consumer of must agree on the scheme(s) being used since
SML-IF only requires consumers to understand the
sml:uri scheme.
Third, when creating a new
sml:ref scheme, authors must be explicit about
whether the scheme is an SML-IF inter-document reference.
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 make inter-document
references to the document in question.
A document element containing no
alias elements[2] signals that the
document in question has no aliases. (By implication having no
alias also signals that there can be no inter-document
references to it.)
Each member of the set of all alias URIs in an SML-IF document must be unique. That is, no two alias URIs in a given SML-IF document may be equivalent.
If any inter-document reference in the
interchange set is a relative URI or if any alias of any document
in the interchange set is a relative URI, the baseURI
child of the identity element must be present
and must contain an absolute URI.
If the URI representing an inter-document reference only contains a fragment, the inter-document reference is to the document in which it occurs. Otherwise, if the URI representing an inter-document reference is equivalent to a URI that is an alias of some document in the interchange set, the inter-document reference is to that document. In either case, such a reference is called “a resolved inter-document reference.” If neither of these cases applies, the inter-document reference is to a document not included in the interchange set. Such a reference is called “an unresolved inter-document reference.”
If the URI representing a resolved inter-document reference has no fragment, the reference is to the root element of the referred-to document.
If the URI representing a resolved inter-document reference has a fragment, the reference is to the element obtained by applying the fragment to the referred-to document starting with its root element.
By definition, unresolved inter-document references are references to documents (or to elements in documents) not included in the interchange.
To associate SML rule documents with the subset of documents in the model to which they apply, SML-IF uses a combination of alias mechanism described above 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 at any point in “climbing the ladder” of URI equivalence testing described in RFC-3986, Section 6.1 [7] the target, truncated to the length of the prefix, is equivalent to the prefix.
Given a prefix and a set of URIs, the matching set of the prefix is that subset of the URIs that match the prefix.
A 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 bindings. In any given binding the set of rule
documents is that subset of rule documents in the interchange set
with an alias that matches the URI prefix given by the content of
the ruleAlias element. The set of model documents in
the binding is that subset of the documents in the interchange set
with an alias that matches the URI prefix given by the content of
the documentAlias element. If the
documentAlias element is omitted in a
ruleBinding, the set of model documents in the binding
is all documents in the interchange set.
Although SML-IF itself does not do so, various uses of SML-IF may well 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.
Appendix A – [Normative] SML-IF Schema
<?xml version="1.0" encoding="utf-8"?>
<!-- Copyright (c) 2006-2007 by
BEA, BMC, CA, Cisco, Dell, EMC, HP, IBM, Intel, Microsoft, and Sun.
All rights reserved. -->
<!-- Permission to copy, display, and distribute this Service Modeling
Language Interchange Format (SML-IF) Schema Document, in any medium
without fee or royalty is hereby granted, provided that you include the
following on ALL copies of the SML-IF Schema Document, or portions
thereof, that you make:
1. A link or URL to the SML-IF Schema Document at this location:
http://schemas.serviceml.org/smlif/2007/02/smlif.xsd
2. The copyright notice as shown in the SML-IF Schema Document.
BEA, BMC, CA, Cisco, Dell, EMC, HP, IBM, Intel, Microsoft, and Sun
(collectively, the "Authors") each agree to grant you a royalty-free
license, under reasonable, non-discriminatory terms and conditions
to their respective patents that they deem necessary to implement the
Service Modeling Language Interchange Format Schema Document.
THE SML-IF SCHEMA DOCUMENT IS PROVIDED "AS IS," AND THE AUTHORS MAKE
NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT
NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS OF
THE SML-IF SCHEMA DOCUMENT ARE SUITABLE FOR ANY PURPOSE; NOR THAT
THE IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY THIRD PARTY
PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS. THE AUTHORS WILL
NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL OR
CONSEQUENTIAL DAMAGES ARISING OUT OF OR RELATING TO ANY USE OR
DISTRIBUTION OF THE SML-IF SCHEMA DOCUMENT.
The name and trademarks of the Authors may NOT be used in any manner,
including advertising or publicity pertaining to the SML-IF Schema
Document or its contents without specific, written prior permission.
Title to copyright in the SML-IF Schema Document will at all times
remain with the Authors.
-->
<!-- Revision History
10/10/06 - Schema created
2007-02-05 Add 2007 to copyright
2007-02-17 2006 namespaces to 2007
-->
<xs:schema xmlns:smlif="http://schemas.serviceml.org/smlif/2007/02"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://schemas.serviceml.org/smlif/2007/02"
elementFormDefault="qualified"
blockDefault="#all"
version="1.0"
xml:lang="EN">
<xs:element name="model" type="smlif:modelType"/>
<xs:complexType name="modelType">
<xs:sequence>
<xs:element name="identity" type="smlif:identityType"/>
<xs:element name="ruleBindings"
type="smlif:ruleBindingCollectionType" minOccurs="0"/>
<xs:element name="definitions"
type="smlif:documentCollectionType" minOccurs="0"/>
<xs:element name="instances"
type="smlif:documentCollectionType" minOccurs="0"/>
<xs:any namespace="##other" processContents="skip" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="skip"/>
</xs:complexType>
<!-- If there is a need for localized string values, e.g. in displayName
or description, the smlerr:localizationid global attribute can be
used
-->
<xs:complexType name="identityType">
<xs:sequence>
<xs:element name="name" type="smlif:uriType"/>
<xs:element name="version" type="smlif:tokenType" minOccurs="0"/>
<xs:element name="displayName" type="smlif:displayType" minOccurs="0"/>
<xs:element name="baseURI" type="smlif:uriType" minOccurs="0"/>
<xs:element name="description" type="smlif:displayType" minOccurs="0"/>
<xs:any namespace="##other" processContents="skip" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="skip"/>
</xs:complexType>
<xs:complexType name="displayType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:anyAttribute namespace="##other" processContents="skip"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="tokenType">
<xs:simpleContent>
<xs:extension base="xs:token">
<xs:anyAttribute namespace="##other" processContents ="skip"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="uriType">
<xs:simpleContent>
<xs:extension base="xs:anyURI">
<xs:anyAttribute namespace="##other" processContents ="skip"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="ruleBindingType">
<xs:sequence>
<xs:element name="documentAlias" type="smlif:uriType" minOccurs="0"/>
<xs:element name="ruleAlias" type="smlif:uriType"/>
<xs:any namespace="##other" processContents="skip" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="skip"/>
</xs:complexType>
<xs:complexType name="ruleBindingCollectionType">
<xs:sequence>
<xs:element name="ruleBinding" type="smlif:ruleBindingType"
maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="skip" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="skip"/>
</xs:complexType>
<xs:complexType name="documentType">
<xs:sequence>
<xs:element name="docinfo" type="smlif:docinfoType" minOccurs="0"/>
<xs:choice>
<xs:element name="data" type="smlif:dataType"/>
<xs:element name="locator" type="smlif:locatorType"/>
</xs:choice>
<xs:any namespace="##other" processContents="skip" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="skip"/>
</xs:complexType>
<xs:complexType name="documentCollectionType">
<xs:sequence>
<xs:element name="document" type="smlif:documentType"
maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="skip" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="skip"/>
</xs:complexType>
<xs:complexType name="docinfoType">
<xs:sequence>
<xs:element name="aliases" type="smlif:aliasCollectionType"
minOccurs="0"/>
<xs:any namespace="##other" processContents="skip" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="skip"/>
</xs:complexType>
<xs:complexType name="aliasCollectionType">
<xs:sequence>
<xs:element name="alias" type="smlif:uriType" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="skip" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="skip"/>
</xs:complexType>
<xs:complexType name="dataType">
<xs:sequence>
<xs:any namespace="##other" processContents="skip" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="skip"/>
</xs:complexType>
<xs:complexType name="locatorType">
<xs:sequence>
<xs:element name="documentURI" type="smlif:uriType" minOccurs="0"/>
<xs:any namespace="##other" processContents="skip" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="skip"/>
</xs:complexType>
</xs:schema>
Appendix B – Normative References
[1]
“Service Modeling Language” Draft Specification Version
1.0, February 2007
<http://www.serviceml.org/SML-200702.pdf>
[2] “XML
Schema Part 1: Structures Second Edition”
<http://www.w3.org/TR/xmlschema-1/>
[3] “XML
Schema Part 2: Datatypes Second Edition”
<http://www.w3.org/TR/xmlschema-2/>
[4]
“Information technology -- Document Schema Definition
Languages (DSDL) -- Part 3: Rule-based validation --
Schematron” ISO/IEC 19757-3:2006
<http://standards.iso.org/ittf/PubliclyAvailableStandards/c040833_ISO_IEC_19757-3_2006(E).zip>
[5]
“XML-Signature Syntax and Processing”
<http://www.w3.org/TR/xmldsig-core/>
[6]
“Canonical XML”
<http://www.w3.org/TR/xml-c14n>
[7]
“Uniform Resource Identifier (URI): Generic
Syntax”
<http://www.ietf.org/rfc/rfc3986.txt>
[8]
“Extensible Markup Language (XML) 1.0, Second
Edition”
<http://www.w3.org/TR/2000/REC-xml-20001006>
[9] “Web
Services Addressing 1.0 - Core”
< http://www.w3.org/TR/ws-addr-core/ >
[10] “Key words for
use in RFCs to Indicate Requirement Levels”
<http://www.ietf.org/rfc/rfc2119.txt>
[11] “Web Services
Description Language (WSDL) Version 2.0 Part 1: Core
Language”
<http://www.w3.org/TR/wsdl20/>
[12] “XML Linking
Language (XLink) Version 1.0”
<http://www.w3.org/TR/xlink/>
[1] That the content of xsi:schemaLocation attributes are inter-document references means that the producer of them intends schemas in the interchange set to be used. It does not mean that consumers must use them. XML Schema processing permits processors to obtain the required schema definitions in any number of ways. SML-IF does not change that.
[2] Note that having no alias element is not the same as having an alias element with no content. A zero length URI is a relative URI equivalent to its base URI. This would be an odd, but legal, choice for an alias.