Copyright © 2006-2007 BEA, BMC, CA, Cisco, Dell, EMC, HP, IBM, Intel, Microsoft, and Sun. All rights reserved. This document is available under the W3C Document License. See the W3C Intellectual Rights Notice and Legal Disclaimers for additional information.
This specification defines the interchange format for SML models.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications can be found in the W3C technical reports index at http://www.w3.org/TR/.
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.
By publishing this document, W3C acknowledges that the Submitting Members have made a formal Submission request to W3C for discussion. Publication of this document by W3C indicates no endorsement of its content by W3C, nor that W3C has, is, or will be allocating any resources to the issues addressed by it. This document is not the product of a chartered W3C group, but is published as potential input to the W3C Process. A W3C Team Comment has been published in conjunction with this Member Submission. Publication of acknowledged Member Submissions at the W3C site is one of the benefits of W3C Membership. Please consult the requirements associated with Member Submissions of section 3.3 of the W3C Patent Policy. Please consult the complete list of acknowledged W3C Member Submissions.
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 the ruleAlias
. 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:
Note: If the SML-IF document uses UTF-8 encoding, the octet-stream result of XML Canonicalization [6] is more than sufficient to accomplish this processing.
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 .
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 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 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.
<?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. --> <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>
[1] “Service Modeling Language” Draft Specification Version 1.0, February 2007
<http://www.w3.org/submissions/2007/SUBM-sml-20070321/>
[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/>