1 Introduction

The “SOA - Repository Artifact Model and Protocol” (S-RAMP) specification defines a common data model for SOA repositories to facilitate the use of common tooling and sharing of data. It provides a rich representation data model that supports query. It includes binding(s) that document the syntax for interaction with a compliant repository for create, read, update, delete and query operations within the context of each binding. Initially, only one binding will be defined, but others can be added.

The specification is organized into multiple documents. This document, the SOA - Repository Artifact Model and Protocol Foundation (hereafter referred to as Foundation) describes the overall goals of S-RAMP and defines the Artifact Type Model and associated schemas for S-RAMP. It also describes the generic query grammar used in S-RAMP. The Foundation document is not specific to any binding. Other documents in this specification provide material specific to a given binding for S-RAMP, including the syntax for interacting with an S-RAMP compliant repository. Those available at the time of this publication are:

S-RAMP Atom Binding

When there is a discrepancy between a binding specific document and this Foundation document, the binding specific document always takes precedence. If there is a discrepancy between schema representations provided in this document and the S-RAMP schemas of record at https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=s-ramp, the schemas of record SHALL take precedence.

1.1 Terminology

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119].

The characters "[" and "]" are used to indicate that contained items are to be treated as a group with respect to cardinality or choice.

1.2 Diagrams used in this document

1.2.1 Attributes and elements

S-RAMP uses the XML Schema Language (See http://www.w3.org/TR/xmlschema-0/, http://www.w3.org/TR/xmlschema-1/ and http://www.w3.org/TR/xmlschema-2/) and its terminology, such as "sequence" and "choice" to formally describe its data structures. The diagrams [1] used in this specification show the structure and cardinality of the elements used in these structures. Attributes are not shown in the diagrams, but explained in the corresponding documentation.

1.2.2 Element structure

The octagonal symbol with the horizontal "dotted" line indicates "sequence of." This diagram says the type BaseArtifactType consists of elements classifiedBy, relationship and properties. All three elements are defined in the namespace whose prefix is "s-ramp".

The fact that relationship and properties have a box with a "+" in it at their right-hand end indicates that there is more structure to them than is shown in the diagram.

1.2.3 Cardinality

1.2.3.1 Optional, one

The dashed line indicates that the element directsOrchestration is optional. The fact that it is not adorned with some other cardinality indicator (see below) says there can be at most one of them.

1.2.3.2 Mandatory, one

There must be exactly one of the element relatedDocument.

1.2.3.3 Optional, repeating

The element classifiedBy is optional and may appear an indeterminate number of times. The number of times it may appear is given by the adornment "0..¥", a cardinality indicator meaning "zero to infinity". Other numbers may appear to indicate different cardinalities.

1.2.3.4 Mandatory, repeating

The element policies must appear at least once and may appear an indeterminate number of times.

1.3 Normative References

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997. http://www.ietf.org/rfc/rfc2119.txt.

[SOAONT] Service Oriented Architecture Ontology. October 2010. The Open Group. http://www.opengroup.org/projects/soa-ontology/

1.4 Non-Normative References

[XML] Extensible Markup Language (XML) 1.0 Specification (Fifth Edition). November 2008. W3C Recommendation. http://www.w3.org/TR/2008/REC-xml-20081126/

[XMLNS] Namespaces in XML 1.0 (Second Edition). August 2006. W3C Recommendation. http://www.w3.org/TR/2006/REC-xml-names-20060816/

[XSD] XML Schema Part 1: Structures Second Edition, version 1.0. October 2004. W3C Recommendation. http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/

[XPATH] XML Path Language (XPath) 2.0 (Second Edition). December 2010. W3C Recommendation. http://www.w3.org/TR/2010/REC-xpath20-20101214/

[RDF] RDF Primer. February 2004. W3C Recommendation. http://www.w3.org/TR/2004/REC-rdf-primer-20040210/

[OWL] OWL Web Ontology Language Guide. February 2004. W3C Recommendation. http://www.w3.org/TR/2004/REC-owl-guide-20040210/

[WSDL] Web Services Description Language (WSDL), Version 1.1. March 2001. W3C Note. http://www.w3.org/TR/2001/NOTE-wsdl-20010315

[ISO6392] Codes for the Representation of Names and Languages – Part 2. 1998. ISO 639-2. http://www.loc.gov/standards/iso639-2/normtext.html

[WSFWK] Web Services Policy 1.5 – Framework. September 2007. W3C Recommendation. http://www.w3.org/TR/2007/REC-ws-policy-20070904

[WSATTCH] Web Services Policy 1.5 – Attachment. September 2007. W3C Recommendation. http://www.w3.org/TR/2007/REC-ws-policy-attach-20070904

[UUID] P. Leach, M. Mealling, and R. Salz, A Universally Unique IDentifier (UUID) URN Namespace. July 2005. IETF RFC 4122. http://www.ietf.org/rfc/rfc4122.txt

[QUERYOPS] XQuery 1.0 and XPath 2.0 Functions and Operators (Second Edition). December 2010. W3C Recommendation. http://www.w3.org/TR/2010/REC-xpath-functions-20101214/

1.5 Problem Statement and Objectives

Service Oriented Architecture (SOA) is an architectural approach to designing applications and business processes by consuming business logic from reusable software components exposed as network accessible services. In today’s environment, vendors offer tools to facilitate various activities across the life cycle of a SOA artifact, such as design, assembly, quality assurance, deployment and runtime operation of SOA based applications and business processes. The SOA repository provides the foundation for all these activities. This specification describes how to represent SOA information models using artifacts and associated metadata, the Artifact Type Model that defines the artifacts, and the bindings to interact with the SOA repository, including create, read, update, delete, query, and subscription for notifications. This approach to providing flexible access to SOA artifacts will facilitate interoperability and provide customers with more choices of tools that can be used to interoperate with any S-RAMP compliant SOA repository implementation.

1.6 Use Case Scenarios

Table 1, Table 2 and Table 3 below provide some examples across different portions of the service lifecycle for which there are various use cases in which an S-RAMP compliant repository could be used. This does not necessarily imply that all vendors would support every scenario, or use an S-RAMP repository in each of these scenarios across all portions of the service lifecycle.

Table 1: Design Time Tool Repository Interaction Use Cases

Tool Category

Activities

S-RAMP Feature

Examples

Integrated Development Environment (IDE)

1. Design WSDL and schemas

2. Publish and consume services

3. Publish SCA into repository

4. Asset Relationship Visualization

5. Notification to service developer when WSDL changes

WsdlDocument

XsdDocument

OWL classifications

PortType

WID

RSA

Together

VisualStudio

Oracle JDeveloper

Business Process Modeling Tools

1. Publish WSDL descriptions for processes

2. Look for process entry points

3. Search/find services to use in business processes

4. Impact analysis

wsdDocument

XsdDocument

OWL classifications

PortType

WebSphere Business Modeling

ARIS Platform

Oracle (Collaxa)

TIBCO Business Studio

Table 2: Run Time Tool Repository Interaction Use Cases

Tool Category

Activities

S-RAMP Feature

Examples

Testing

1. Search to find a WSDL

2. Understand policies associated with WSDL

3. Understand relationships between SOA components

4. Notification when WSDL changes

WsdlDocument

Service

PolicyAttachment

Policy

HP Service Test Manager

Rational Testing Tools

Itko Lisa

ESB

1. Dynamic routing based on #services, requestor type, etc.

2. Notifications of new artifacts, changes/deletions

3. Track information on lifecycle and operational state (e.g., using classifications, properties, etc.)

PolicyAttachment

WSDL Parts

Service properties

DataPower

WebSphere ESB

Oracle Service Bus

SAP XI

WebMethods

TIBCO ActiveMatrix

Policy Mgmt

1. Edit and store policies

2. Query repository for policies to deploy/provision

3. Execute (enforce) policy

4. Update managed endpoint in repository

PolicyAttachment

policy

service

ServiceEndpoint

AmberPoint

Actional

HP SOA Policy Enforcer

CentraSite

TIBCO ActiveMatrix Policy Manager

Table 3: Monitoring Tool Repository Interaction Use Cases

Tool Category

Activities

S-RAMP Feature

Examples

Service Monitoring

1. Retrieve service definitions from repository

2. Update service information with performance and availability data

3. Discover dependencies between business services and web service instances

4. Discover what organizations provide a service

5. Discover operational data for the service for monitoring

Organization

Service

ServiceInstance

ServiceOperation

user properties

Tivoli CAM for SOA

BAC for SOA

AmberPoint

Actional

WebMethods Insight

TIBCO ActiveMatrix Service Performance Manager

1.7 Design Principles

There are several high-level design principles to which S-RAMP has adhered:

Use of existing standards where possible (e.g., XML, XML Schema, OWL, XPath2, APP (Atom Publishing Protocol), ASF (Atom Syndication Format), etc.).
Vendor neutrality.
Does not include governance models, but may be used by them.
Driven by use cases.
Data model extensibility for new data types, and support for system and user defined metadata.
Inclusion of an XML Schema based serialization for its data model.
Use of XPath 2 to describe its query grammar.
Use of OWL Lite to describe its classification system grammar.
Separation of the data model from the bindings that describe the interaction APIs clients use to interact with the repository.

1.8 S-RAMP Schemas

The schemas for the various S-RAMP Models are provided in the appendices. They closely follow the conceptualized diagrams described in this document. The normative S-RAMP schemas of record define the serialization for S-RAMP.

Notable points concerning the schemas in S-RAMP include:

Built-in properties are typically represented as attributes.
Types based on BaseArtifactType use an extension of that type as their base.
Where practical, Global Element Declarations are provided.
Extensibility in the Core Model is limited to the ##any attribute on most structures.

Schemas are provided for serialization purposes and the diagrams define the S-RAMP meta-model.

1.9 XML Namespaces

The XML namespace URI that MUST be used by implementations of this specification is:

http://docs.oasis-open.org/s-ramp/ns/s-ramp-v1.0

Table 4 lists the XML namespaces that are used in this specification. The choice of any namespace prefix is arbitrary and not semantically significant.

Table 4: Prefixes and XML Namespaces Used in this Specification

Prefix	XML Namespace	Specification(s)
xp2	http://www.w3.org/2005/xpath-functions	XPath 2.0
rdf	http://www.w3.org/1999/02/22-rdf-syntax-ns#	RDF namespace
rdfs	http://www.w3.org/2000/01/rdf-schema#	RDFS namespace
owl	http://www.w3.org/2002/07/owl#	OWL namespace
s-ramp	http://docs.oasis-open.org/s-ramp/ns/s-ramp-v1.0	S-RAMP namespace
wsdl	http://schemas.xmlsoap.org/wsdl/	WSDL [WSDL 1.1]
wsp	http://www.w3.org/TR/2007/REC-ws-policy-20070904	WS-Policy [WS-Policy]
xsd	http://www.w3.org/2001/XMLSchema	XML Schema [Part 1, 2]

2 Artifact Type Model

The S-RAMP Artifact Type Model is a strongly typed data model for SOA repositories that enables interoperability among vendor repository implementations and tooling, within the context of a specific binding. It will also later serve as a foundation for developing data exchange and federation models. The Artifact Type Model is presented here using conceptualized models. Each of these models also has a XML Schema representation available in the Appendices.

2.1 Artifact Type Models

An artifact in S-RAMP is a container for all of the metadata that describes it. There are 4 major types of artifacts in S-RAMP. Each of these Artifact Types is discussed in more detail in later sections:

Document Artifact: Those S-RAMP defined artifacts that correspond to a physical document stored in the repository. Several important document types are pre-defined and have special support in S-RAMP (such as XML Schema or WSDL documents). But any document type can be placed in the repository.
Logical Model Artifact: Those S-RAMP defined artifacts that provide a representation of one of the pre-defined logical models (e.g. the SOA model or Service Implementation model).
Derived Artifact: Derived Artifacts (e.g., WSDL PortType, or WS-Policy PolicyExpression) are dynamically instantiated by the server as a consequence of publishing a document instance whose type is one of those supported with a Derived Model (see Table 5). These artifacts cannot be created or deleted directly, although clients can edit them to add or remove Generic relationships, properties and classifications. Derived Artifact Models are managed by the server and kept in synchronization with the document object with which they are associated. Derived artifacts provide a metadata model of the content components of a particular document. This allows much more powerful query capabilities at a granularity specific to the internal components of a document, when it is of a format supported with a Derived Model. Refer to Section Error! Reference source not found. for more information on the query model supported in S-RAMP, as well as to the individual binding document(s) for the query syntax pertaining to each binding.
Extended Artifact: These are created by the client in order to support artifact models not pre-defined by the S-RAMP specification. The means by which a client specifies a custom artifact model are beyond the scope of this specification, but some provision is made within the S-RAMP schema to facilitate basic interoperability for such artifacts. Regardless of the internal definition of these artifacts, they SHALL be serialized in S-RAMP as either an instance of ExtendedArtifactType (which extends BaseArtifactType), or as an instance of ExtendedDocument (which extends DocumentArtifactType). The latter should be used by clients when the custom artifact contains document content.

The pre-defined S-RAMP Artifact Types are organized into a set of logical models as summarized in Table 5 below. Each of these is discussed further in the sections that follow. Note that Derived Artifact Models are currently specified for each of the XSD, WSDL, and WS-Policy document types.

Table 5: Pre-Defined Artifact Type Models

Model	Purpose
Core	Defines the base data types used by the other models, as well as generic types for Documents and XML Documents.
SOA	Defines the artifact data types and relationships which are used to integrate The Open Group’s SOA Ontology object model into S-RAMP’s data model.
Service Implementation	Defines the artifact data types and relationships used to model the service implementation layer of a SOA environment.
Derived: XSD	Defines logical artifact data types for an XML Schema document.
Derived: WSDL	Defines logical artifact data types for a WSDL document.
Derived: SOAPWSDL	Defines artifact data types for the SOAP binding of a WSDL document.
Derived: Policy	Defines artifact data types for a WS-Policy document.

2.1.1 Artifact Metadata

An artifact can contain three major types of metadata. Each is discussed in detail in the sections that follow.

Relationships: These are directed associations that describe a conceptual link between two artifact instances. There are several types of relationships, which are defined below in Section Error! Reference source not found..
Properties: These describe various named attributes associated with an artifact instance, and can be built-in or user-defined. Each S-RAMP property MUST have a single name that is unique to the artifact that it decorates. When present, an S-RAMP property SHALL have a single value.
Classifications: These define the classification system for a server, and are imported into a server as OWL documents. The means by which a client imports the system into the server is implementation specific and is beyond the scope of this specification. Clients MAY decorate artifacts with references to specific values in a classification system defined to the server.

Note that Artifact Type and Artifact Model values MUST also be unique.

2.1.2 Artifact Relationships

Relationships in S-RAMP are all directed from a source, to a target. Each relationship instance is the logical triple of the following 3 items of metadata:

Relationship Type. This is the name for the type of relationship. A number of these are pre-defined by S-RAMP in the various Artifact Models (e.g., “includedXsds”, “appliesTo”, …). There can be multiple relationship instances of the same Relationship Type.
Source. This is a reference to the artifact that is on the source side of the directed relationship. Relationships are always contained by the Source Artifact that “owns” them.
Target. This is a reference to the artifact that is on the target side of the directed relationship.

It is possible for a relationship of a given Relationship Type not to have a target, which is termed a “relationship with no targets”. In this case there is only one relationship instance with that Relationship Type for a given Source. Such relationships have a target cardinality of “0”. If there is a relationship instance with a given Relationship Type that does have a target, then there CANNOT also be a relationship instance with that Relationship Type which has no target.

There are 4 types of relationships supported in S-RAMP. Refer to the table in Appendix Error! Reference source not found. for a complete list of pre-defined relationships, an indication of whether the relationship is derived, and the model in which it occurs.

Derived Relationships. These are pre-defined relationships that cannot be directly created or deleted by the client. Cardinalities for such relationships are defined in the applicable Derived Model. All instances of an Artifact Type for which a Derived Relationship is defined, will always contain that Derived Relationship, even if there are no targets for that relationship. The S-RAMP serialization of a Derived Relationship uses named elements defined in the schema for the appropriate Artifact Type definition(s).
Modeled Relationships. These refer to the S-RAMP pre-defined relationships that may be edited by the client. Cardinalities for such relationships are defined in the applicable model (e.g., the Service Implementation Model or Core Model). All instances of an Artifact Type for which a Modeled Relationship is defined, will always contain that Modeled Relationship, even if there are no targets for that relationship. The S-RAMP serialization of a Modeled Relationship uses named elements defined in the schema within the applicable Artifact Type. There are several considerations related to target cardinality of Modeled Relationships:

· Modeled Relationships with Minimum Cardinality = 0:

· Instances of the Source Artifact can be created independently of the Target Artifact.

· Modeled Relationships with Minimum Cardinality > 0:

· Instances of the Source Artifact cannot be created without the appropriate Target Artifact(s) based upon the required minimum cardinality of the relationship.

· This can be accomplished by publishing the relevant artifacts at the same time, or by publishing the target artifact(s) first.

· Actions that result in the deletion of a relationship instance are not permitted if that would result in a violation of the minimum cardinality.

· Modeled Relationships with Maximum Cardinality < unbounded:

· Relationship instances cannot be created if that would result in a violation of the maximum cardinality limit for the Modeled Relationship.

Note that in cases where the minimum cardinality equals the maximum cardinality, such a relationship must be created or updated in a single step to avoid intermediate states that would violate these requirements.

Generic Relationships. These are user-defined ad-hoc directed relationship instances between any two artifacts in S-RAMP. They always have a minimum cardinality of 0 and an unbounded maximum cardinality. The Relationship Type value of a Generic Relationship instance is chosen by the client, but it MUST NOT match any pre-defined Relationship Type values already defined by the S-RAMP Modeled and Derived relationships (see Appendix Error! Reference source not found.). The S-RAMP serialization of a Generic Relationship uses the relationship structure defined in the Core Model.
Extended Artifact Modeled Relationships. Users may define their own extended artifact models, which may include modeled relationships. How and whether such models are supported is beyond the scope of this specification. Such models are called “Extended Models”. Since pre-defined relationships in a model are termed “Modeled”, then in this context they are called “Extended Modeled Relationships”. The S-RAMP serialization of an Extended Modeled Relationship uses the S-RAMP relationship structure defined in the Core Model.

2.2 The Core Model

There is a “core” model that defines all the basic Artifact Types used throughout S-RAMP. The Core Model contains abstract base artifacts for document artifacts and derived artifacts (which are associated with certain document types). Most Artifact Types in the other S-RAMP models are extensions of BaseArtifactType. Additionally, the Core Model includes the Document and XmlDocument concrete Artifact Types.

Figure 1: Conceptualized Model of Core Model Artifacts

Error! Reference source not found. provides a conceptualized illustration of the Core Model artifacts. In addition, there are a number of support types used by the core and other models. Note that the class attributes in the diagram are essentially built-in properties. The remaining sub-sections provided additional details on the Core Model.

2.2.1 Base Artifact Type

The BaseArtifactType is the fundamental abstract type used by all of the artifact models in S-RAMP. It contains all of the common metadata that describes an artifact instance. All artifact instances that are based on the BaseArtifactType contain the following metadata.

2.2.1.1 Built-in Properties:

artifactType: A required string which is set when a specific type of artifact is created. These artifact types are enumerated in a list of core data types. The enumeration is defined by the baseArtifactEnum.
createdBy: A required string assigned by the server identifying the user who created the artifact. S-RAMP does not define requirements on this value. These are implementation specific.
createdTimestamp: A required timestamp which is set by the server at the time an artifact is first published. It conforms to xsd:dateTime, referenced to UTC.
description: This optional property is used to provide a human consumable description of the artifact instance. This value is set by the client for all non-Derived Artifacts (although implementations MAY support setting it automatically using introspection. Derived Artifact descriptions are set by the server.
lastModifiedBy: A required string assigned by the server identifying the user who last updated the artifact. S-RAMP does not define requirements on this value. These are implementation specific.
lastModifiedTimestamp: A required timestamp which is updated by the server each time an artifact instance is modified. It conforms to xsd:dateTime, referenced to UTC.
name: This required property is used to describe the artifact instance. This value is set by the client for all non-Derived Artifacts (although implementations MAY support setting it automatically using introspection). Derived Artifact names are set by the server.
uuid: A required unique identifier of an artifact instance in the repository. This value conforms to Type 4 random-number format UUIDs [UUID], and is set for the artifact at the time of its creation. The repository will assign a value if the user does not provide one.
version: An optional string representing the version of the artifact instance. S-RAMP makes no attempt to define formatting rules for this property, which are implementation specific.

2.2.1.2 Generic Properties

property: These are optional properties which are defined by the client. They MUST have a single unique name (which SHALL NOT duplicate any other property name of any type, and SHALL NOT duplicate any Relationship Type value). A property name SHALL have 0 or 1 value.

2.2.1.3 Generic Relationships

relationship: These are optional relationship(s) defined by the client. A relationship contains a Relationship Type identifying the type of the relationship, and 0 or more target artifact references. Relationship Type values within a relationship SHALL NOT duplicate the name of any property.

2.2.1.4 Classifications

classifiedBy: This is a separate class of metadata. It MAY be set by the client with an unbounded upper cardinality limit. Each value SHALL be a URI that references a specific OWL class from a classification system defined to the repository. For more on OWL classification systems in S-RAMP, see Section Error! Reference source not found..

2.2.2 Document Artifact Types

The DocumentArtifactType is the fundamental abstract data type for all documents represented in the repository, and it extends BaseArtifactType. This Artifact Type includes several built-in properties:

contentType:

A string indicating the MIME Media type of the content. This is set by the server as part of processing the publication of the document, and cannot be changed by the user.

contentSize:

An integer representing the size of the content in bytes. This is set by the server as part of processing the publication of the document. It cannot be changed by the user.

contentHash:

A string representing the SHA-1 hash of the document’s byte contents. This is set by the server as part of processing the publication of the document. It cannot be changed by the user.

The Core Model also includes an XmlDocument type that all XML based document data types extend. The Document type provides a concrete artifact that can be used to represent arbitrary document types (e.g. PDF or Office documents).

Documents which have a Derived Model associated with them cannot be updated in the repository. They must be removed and republished.

Documents which are the target of a relationship cannot be deleted.

2.2.3 Miscellaneous Types

There are a few miscellaneous classes in the Core Model:

StoredQuery:

This is a special Artifact Type that is used to persist queries in the repository. Additional information on this topic is available in Section Error! Reference source not found., Error! Reference source not found..

ExtendedArtifactType:

The ExtendedArtifactType allows clients to create their own extended artifact model when it is not pre-defined by the S-RAMP specification. The extendedType property is intended to provide an indication of the artifact type.

ExtendedDocument:

The ExtendedDocument allows clients to create their own extended artifact model when it is not pre-defined by the S-RAMP specification. The extendedType property is intended to provide an indication of the artifact type. This differs from the ExtendedArtifactType in that it extends DocumentArtifactType, thereby inheriting its properties. This type may be used by clients when adding extended artifact model artifacts that contain document content.

2.3 Modeling SOA Concepts

S-RAMP supports modeling of business level SOA concepts related to service and process representations and interactions. Since it is not the mission of S-RAMP to define a “SOA Ontology” for the industry, this specification has chosen to reference work done by The Open Group in their “SOA Working Group” on the “SOA Ontology” (see http://www.opengroup.org/projects/soa-ontology/). That work is compatible with both SCA and BPMN but draws both service and process concepts together at a higher level of abstraction.

S-RAMP supports modeling of SOA concepts using a layered approach:

S-RAMP SOA Model
S-RAMP Service Implementation Model

The sections below describe how the SOA Ontology work is integrated with S-RAMP as well as the implementation layer underneath it.

2.3.1 The SOA Model

The S-RAMP SOA Model exists to provide a mechanism to link work done by The Open Group SOA Ontology work group ([SOAONT]) with the rest of the S-RAMP internal models. It defines a very minimal set of linkages to artifacts defined in the SOA Ontology.

Several S-RAMP modeling features have been defined in order to provide linkage between the SOA Ontology and the S-RAMP data model. This is done using the S-RAMP SOA Model. Artifact Types in this model are all user instantiated, and are described in the S-RAMP SOA Model illustrated in Figure 2 below.

Figure 2: Conceptualized Model of SOA Model Artifacts (part 1)

Figure 3: Conceptualized Model of SOA Model Artifacts (part 2)

SOA Model artifacts and the SOA Ontology artifacts referenced by the SOA Model are designed to provide clients the ability to create conceptual SOA representations. SOA Model Artifacts are all logical artifacts and do not represent or correspond directly to a document instance, as do those in the Derived Models.

S-RAMP provides an XML Schema representation of the S-RAMP SOA Model, including elements corresponding to the base version of The Open Groups SOA Ontology’s defined artifacts, within the context of the S-RAMP data model. It can be found in Appendix Error! Reference source not found..

2.3.1.1 SOA Model Artifact Types and Relationships

The abstract SoaModelType Artifact Type implicitly acts as a super class for ALL top level SOA Ontology artifacts when they are used within the context of S-RAMP. This imbues all of them with the properties built into all S-RAMP Artifact Types. S-RAMP adds several relationships to SOA Ontology Artifacts used in the SOA Model in order to provide a connection from the SOA Ontology artifacts into the implementation level artifacts described in the Service Implementation Model in Section Error! Reference source not found..

SOA Model Artifacts MAY have relationships to Document Artifacts and/or Derived Artifacts in other models, as well as among themselves. All the relationships defined in the SOA Model are Modeled Relationships. See Section Error! Reference source not found. for behavioral details associated with Modeled Relationships. The relationships that have been added to artifacts from the SOA Ontology are summarized in Error! Reference source not found. below.

Table 6: SOA Model Relationships

Relationship Name	Source Artifact Type (from SOA Ontology)	Target Artifact Type (from S-RAMP Business & Core Models)	Notes
hasInstance	Service	ServiceInstance
hasOperation	ServiceInterface	ServiceOperation
interfaceDefinedBy	ServiceInterface	DerivedArtifactType	This allows one to indicate the Derived Artifact instance which defines this service interface. For example, this could be PortType artifact instance from the WSDL Model.
policyDefinedBy	Policy	DerivedArtifactType	This allows one to link the SOA Model Policy artifact with a concrete S-RAMP derived artifact type (e.g., PolicyAttachment)
informationTypeDefinedBy	InformationType	DerivedArtifactType	This allows one to link the SOA Model InformationType artifact with a concrete S-RAMP derived artifact type (e.g., PolicyAttachment)

2.3.2 The Service Implementation Model

S-RAMP defines a “Service Implementation Model” which describes the service implementation layer underneath the SOA Model. Artifact Types in this model are all user instantiated and most are extensible. Each of these artifacts derives from the ServiceImplementationModelType and may be created, changed, updated and deleted by the client. There are a number of pre-defined Modeled Relationships between artifacts of particular types. Error! Reference source not found. below illustrates the conceptualized Service Implementation Model artifacts.

Figure 4: Conceptualized Model of Service Implementation Model Artifacts

S-RAMP provides an XML Schema representation of the Service Implementation Model. It can be found in Appendix Error! Reference source not found.. The sub-sections that follow discuss each of the Service Implementation Artifact types in more detail.

2.3.2.1 Service Implementation Model Artifact Types and Relationships

The primary Artifact Type from which all Service Implementation Model Artifacts extend is the abstract ServiceImplementationModelType. The concrete Service Implementation Model Artifacts that extend it are designed to provide the implementation layer below the SOA Model which allows clients to build SOA representations. Service Implementation Model Artifacts are all logical artifacts and do not represent or correspond directly to a document instance as do those in the Derived Models.

Service Implementation Model Artifacts MAY have relationships to Document Artifacts and/or Derived Artifacts in other models, as well as among themselves. All the relationships shown in the Service Implementation Model are Modeled Relationships. See Section Error! Reference source not found. for behavioral details associated with Modeled Relationships. Of note for the ServiceImplementationModelType is the documentation Modeled Relationship which allows any artifact in the Service Implementation Model to reference a document describing it.

The concrete Service Implementation Model Artifact Types are then:

Organization

The Organization type is used to describe an organizational entity. It is a subclass of the “Human Actor” artifact defined in the SOA Ontology. Clients can define an unlimited number of organizations and can use the provides relationship to link an Organization to any Service Implementation Model Artifact

ServiceInstance

The ServiceInstance Artifact Type represents deployed instance(s) of a service. For example, a Web service running in WebSphere, or Oracle Fusion, etc. The describedBy Modeled Relationship can be used to reference document artifact(s) that describe it.

ServiceEndpoint

The ServiceEndpoint Artifact Type represents a physical location at which the Service instance can be invoked, using its url Modeled Property. The endpointDefinedBy Modeled Relationship allows indicating the Derived Artifact instance that defines this Service endpoint is defined. For example, this could be a Port artifact instance from the WSDL Model.

ServiceOperation

The ServiceOperation Artifact Type represents the specific operation performed by the Service. The operationDefinedBy Modeled Relationship can be used to link a ServiceOperation with a Derived Artifact which defines it. For example this could be an Operation artifact instance from the WSDL Model.

2.4 Derived Models

The sections that follow describe the logical models that are constructed by the repository in response to publication of a document for which a Derived Model is defined. The server parses these documents upon publication, dynamically constructing Derived Artifacts corresponding to the major data type components of the document. Every Derived Artifact instance has a relatedDocument relationship to the document from which it was created. The artifacts and relationships in a Derived Model provide a powerful tool for searching the repository based on specific components of such a document (e.g., a WSDL PortType, etc.). In most cases, the model diagrams illustrated in this section are adequate to define the Artifact Types and the Derived Relationships between them, so these sections are correspondingly brief.

Appendix Error! Reference source not found. describes all of the Derived Model schemas defined in S-RAMP.

2.4.1 The XSD Model

The XSD Model describes the Artifact Types that correspond to components of an XSD document stored in the repository, and yields structural metadata useful in performing queries. The conceptual model describing the XSD Model is illustrated below in Figure 5: Conceptualized Model of XSD Model Artifacts.

Figure 5: Conceptualized Model of XSD Model Artifacts

Note that an XSD document MAY include, import, or redefine other XSD documents. These capabilities are modeled using the includedXsds, importedXsds and redefinedXsds Derived Relationships, respectively.

A SimpleTypeDeclaration artifact instance is generated for each global simple type defined in the associated XML Schema document. Similarly, a ComplexTypeDefinition instance is generated for each global complex type defined in that XML Schema document. Each global attribute declared in the XML Schema document will generate a corresponding AttributeDeclaration artifact instance, and finally, each global element declared in the XML Schema document will generate a corresponding ElementDeclaration artifact instance.

While it is possible to construct a more fine-grained model of an XML Schema document, this level of modeling provides a suitably rich context for discovery queries without creating an overly complex model.

2.4.2 The WSDL Model

The WSDL Model is one of the most complex Derived Models, owing to the complexity of WSDL itself. The WSDL Model contains substantial richness because of the value in being able to perform highly refined queries using logical artifact representations of most of a WSDL document’s constituent components.

Figure 6 and Figure 7 below provide a conceptual model representing the logical artifacts and their Derived Relationships in the WSDL Model. This model is intended to mirror the structure of a WSDL file. In most cases, the artifact names exactly match corresponding data types in WSDL (e.g., Message, PortType, Operation, Binding, Service, Port, and so on).

Figure 6: Conceptual Diagram of WSDL Model: Part 1

Figure 7: Conceptual Diagram of WSDL Model: Part 2

Note that aggregation relationships in these diagrams are modeled as Derived Relationships in the WSDL Model schema found in Appendix Error! Reference source not found..

Note that the WsdlExtension Artifact Type illustrated in Figure 7 below is used to model extensibility elements for any given WSDL element. This supports WSDL extensions that the repository does not recognize.

The WsdlDerivedArtifactType is a modeling convenience from which all WSDL related metadata artifacts extend. It contains a namespace attribute that is the namespace of the WSDL document and it applies to every Derived Artifact instance for that Document. It also has an extension Derived Relationship which serves to identify the set of WSDL extensions which apply to the Derived Artifact.

A WSDL document can import, include and redefine XSD document(s), as well as import other WSDL documents. These capabilities are modeled using the importedXsds, includedXsds, redefinedXsds, and importedWsdls relationships, respectively. .

2.4.3 The SOAPWSDL Model

The SOAPWSDL Model contains the SOAP 1.1 binding specific WSDL Model artifacts for WSDL 1.1. It is separated into its own Model and schema to simplify its use. Figure 8 below illustrates a conceptual model of the relevant SOAP WSDL Model artifacts.

Figure 8: Conceptualized Diagram of the SOAP WSDL Model

2.4.4 The Policy Model

The Policy Model describes the Artifact Types that correspond to the primary components of a WS-Policy document. Policy expressions can be in a standalone policy document, or embedded in another document such as a WSDL. Figure 9 below is a conceptual diagram of the Policy Model:

Figure 9: Conceptualized Model of Policy Model Artifacts

All appliesTo relationships are instantiated in the repository based on the content in the policy attachment document. There is no restriction on the artifacts it can reference.

2.5 Referencing S-RAMP Artifacts

The syntax for referencing Artifact Type(s) is defined in each of the S-RAMP bindings (e.g., the S-RAMP Atom Binding). Please refer to the appropriate binding specific document of this specification for details.

2.5.1 Notional Syntax

One possible syntax is as follows and is used in several examples within this specification:

/s-ramp/{ArtifactModel}/{ArtifactType}

Note that each successive component of this syntax is optional. Specifically

A reference of “/s-ramp” refers to all Artifact Types in all models
A reference of “/s-ramp/{Artifact Model}” refers to all Artifact Types within the specified Artifact Model.
References of the form “//{ArtifactModel}” or “//{ArtifactType}” are also permitted.

Table 7: Artifact Models and Types below provides the pre-defined values for Artifact Model and Artifact Types. Abstract types are not included since they cannot be instantiated.

Table 7: Artifact Models and Types

Artifact Model	Artifact Type
core	Document
core	XmlDocument
xsd	XsdDocument
	AttributeDeclaration
	ElementDeclaration
	SimpleTypeDeclaration
	ComplexTypeDeclaration
policy	PolicyDocument
	PolicyExpression
	PolicyAttachment
soapWsdl	SoapAddress
soapWsdl	SoapBinding
wsdl	WsdlDocument
	WsdlService
	Port
	WsdlExtension
	Part
	Message
	Fault
	PortType
	Operation
	OperationInput
	OperationOutput
	Binding
	BindingOperation
	BindingOperationInput
	BindingOperationOutput
	BindingOperationFault
serviceImplementation	Organization
	ServiceEndpoint
	ServiceInstance
	ServiceOperation
ext	{ExtendedType}
soa	{See The Open Group’s SOA Ontology for the normative list of Artifact names. They are reproduced here for clarity.}
	HumanActor
	Choreography
	ChoreographyProcess
	Collaboration
	CollaborationProcess
	Composition
	Effect
	Element
	Event
	InformationType
	Orchestration
	OrchestrationProcess
	Policy
	PolicySubject
	Process
	Service
	ServiceContract
	ServiceComposition
	ServiceInterface
	System
	Task

Below are some examples of S-RAMP model and Artifact Type references using the notional syntax described above.

Example 1: Artifact Model and Type References

/s-ramp

o References all Artifact Types in the repository

/s-ramp/xsd or //xsd

o References all Artifact Types in the XSD Model (e.g., XsdDocument, XsdType, …)

/s-ramp/xsd/XsdType or //XsdType

o References the XsdType Artifact Type in the XSD Model

/s-ramp/soa/Service

o References all Service Artifacts Types in the SOA Model (included by reference to The Open Group’s SOA Ontology)

/s-ramp/wsdl/Port

o References the Port Artifact Type in the WSDL Model

3 Classification Systems in S-RAMP

A classification system allows classification values to be organized in a hierarchy, allowing artifacts to be grouped into sets and to identify subsets within those sets. Query and display of all artifacts in a set then becomes possible and provides a simple yet powerful means of classifying and finding related objects. Artifact instances in the repository MAY have classification values applied to them.

A simple example of a classification system hierarchy is a geographical region hierarchy that could, for example, be used to indicate which location produced an artifact. Using '/' to delineate levels in the hierarchy and ',' to separate members at the same level, one part of an example hierarchy could be World / Asia / Japan, China. The hierarchy could also contain World / Europe / United Kingdom, Germany. In other words, subsets of World are Asia and Europe, subsets of Asia are Japan and China, and subsets of Europe are United Kingdom and Germany. To find artifacts produced by teams in Asia, a search can be issued to return artifacts classified by the Asia classification. To give the behavior desired, a repository implementation interprets this query as requiring the retrieval of artifacts classified by Asia and its sub-groups i.e. Asia or Japan or China.

Classification systems used in S-RAMP are expressed in the Web Ontology Language (OWL) that builds upon the Resource Description Framework (RDF). The RDF/XML serialization format is commonly used for files containing OWL constructs and is a format that SHALL be understood by an S-RAMP repository. OWL consists of three increasingly expressive sublanguages, OWL Lite, OWL DL and OWL Full. The W3C "OWL Web Ontology Language Overview" document indicates that "OWL Lite supports those users primarily needing a classification hierarchy and simple constraints", and accordingly the OWL elements that S-RAMP uses to define classification systems come from OWL Lite. To enable the classification capabilities required in S-RAMP, a restricted set of OWL Lite elements is sufficient. Also, it should be noted that S-RAMP does not support multiple inheritance.

The elements that SHALL be supported and a brief description of each follow (refer to the W3C documents detailing OWL and RDF for further detail on these elements).

rdf:ID

In an element that requires a resource to be identified, an rdf:ID attribute MAY be used. This attribute has slightly different behavior to rdf:about, including the requirement that the value only appear once in the scope of a document, so it provides a useful check when defining distinct resources. RDF and OWL use URIs to identify resources. The attribute value is a string indicating a URI fragment relative to the currently in-scope base value (typically set using the xml:base attribute).

rdf:about

As an alternative to using an rdf:ID attribute to identify a resource, an rdf:about attribute MAY be used. The attribute value is either a string indicating an absolute URI, or a string indicating a relative URI resolved against the currently in-scope base value (typically set using the xml:base attribute).

owl:Ontology

In OWL, classification systems are represented by an OWL ontology. The ontology groups a number of related classifications together. In the example the geographical regions classification system would be defined using an owl:Ontology element.

owl:Imports

owl:Imports elements are permitted under owl:Ontology. This means that classes declared in the ontology MAY subclass classes declared in any imported ontologies, although multiple inheritance is not permitted. How owl ontologies are imported is vendor specific and therefore the resolution of owl:import references is also vendor specific.

owl:Class

OWL represents classifications with OWL classes. In the example, the World, Europe, Asia, United Kingdom, Germany, Japan and China classifications would be defined using an owl:Class element.

rdfs:subClassOf

To define the hierarchy, classes are related to each other via the rdfs:subClassOf element. If class B is declared to be a subclass of class A, then the instances of class B represent a subset of the instances of class A. In the example, Asia would be declared to be a subclass of World, Japan a subclass of Asia, and so on.

rdfs:label

Ontologies and classes MAY be given a human readable name using the rdfs:label element. Names in multiple languages are supported by this element, using the xml:lang attribute.

rdfs:comment

Ontologies and classes MAY be given a human readable comment or description using the rdfs:comment element. Comments in multiple languages are also supported by this element using the xml:lang attribute.

All other OWL elements are not supported (in terms of OWL Lite this means that property-related elements, and the owl:equivalentClass, owl:imports, owl:intersectionOf, and versioning elements are not supported).

OWL files used in S-RAMP MUST conform to the following rules, which result in ontologies that are self-contained in a single OWL file:

There MUST be exactly one owl:Ontology element in any OWL file
A class MUST only be defined in one ontology

The example ontology can be expressed in OWL as follows:

Example 2: An OWL Ontology

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE rdf:RDF [

<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">

<!ENTITY rdf "http://www.w3.org/1999/02/22-rdf-syntax-ns#">

<!ENTITY rdfs "http://www.w3.org/2000/01/rdf-schema#">

<!ENTITY owl "http://www.w3.org/2002/07/owl#">

<!ENTITY ns_region "http://www.regions.com/geographicalregion">

<rdf:RDF

xmlns:xsd="&xsd;"

xmlns:rdf="&rdf;"

xmlns:rdfs="&rdfs;"

xmlns:owl="&owl;"

xmlns:ns_region="&ns_region;"

xml:base="&ns_region;"

<owl:Ontology rdf:ID="">

<rdfs:label>Geographical Regions</rdfs:label>

<rdfs:comment>An ontology used to provide classifications describing geographical regions.</rdfs:comment>

</owl:Ontology>

<owl:Class rdf:ID="World">

<rdfs:label>World</rdfs:label>

<rdfs:label xml:lang="en">World</rdfs:label>

<rdfs:label xml:lang="fr">Monde</rdfs:label>

</owl:Class>

<owl:Class rdf:ID="Asia">

<rdfs:subClassOf rdf:resource="&ns_region;#World"/>

<rdfs:label>Asia</rdfs:label>

</owl:Class>

<owl:Class rdf:ID="Europe">

<rdfs:subClassOf rdf:resource="&ns_region;#World"/>

<rdfs:label>Europe</rdfs:label>

</owl:Class>

<owl:Class rdf:ID="Japan">

<rdfs:subClassOf rdf:resource="&ns_region;#Asia"/>

<rdfs:label>Japan</rdfs:label>

</owl:Class>

<owl:Class rdf:ID="China">

<rdfs:subClassOf rdf:resource="&ns_region;#Asia"/>

<rdfs:label>China</rdfs:label>

</owl:Class>

<owl:Class rdf:ID="UnitedKingdom">

<rdfs:subClassOf rdf:resource="&ns_region;#Europe"/>

<rdfs:label>United Kingdom</rdfs:label>

</owl:Class>

<owl:Class rdf:ID="Germany">

<rdfs:subClassOf rdf:resource="&ns_region;#Europe"/>

<rdfs:label>Germany</rdfs:label>

</owl:Class>

</rdf:RDF>

Some points of interest in the foregoing example:

An rdfs:comment element is shown within the Geographical Regions owl:ontology element, but comments may be used in owl:Class constructs if desired.
rdfs:label elements have generally been used with no xml:lang attribute specified. However, multiple rdfs:label elements MAY be specified within an owl:Ontology or owl:Class element, and these may contain a variety of xml:lang attribute values (and an rdfs:label element with no xml:lang attribute may be specified in addition to elements with such attributes present). The World class in the ontology listed in Example 2 illustrates this. An owl:Ontology or owl:Class element SHOULD contain only one rdfs:label element with a given xml:lang value to ensure well-defined behavior when requesting a label for a specific language.
The behavior of rdfs:comment elements with respect to xml:lang attributes is identical to the behavior for rdfs:label elements.
Although the example shows a single root class which the other classes subclass either directly or indirectly, multiple root classes are permitted in an ontology. Also permitted are stand-alone classes that neither subclasses some parent class nor are themselves parents to other child classes.
Multiple inheritance (a class being a subclass of multiple parent classes) is NOT permitted.

4 S-RAMP Query Model

The S-RAMP specification supports a robust query interface that compliant implementations MUST support. It provides a way to find repository artifacts using a rich set of constraints. The query expression in S-RAMP uses an XPath 2.0 based dialect. Refer to Section Error! Reference source not found. for additional information on the S-RAMP query grammar. The expression predicates act as filters to identify matching artifact instances. Filtering can be done based upon artifact metadata, including properties, relationships and classifications. Complex criteria can be formed. One can for example, search for “all services which are categorized as being in production”, or find “all the XML Schema documents which are referenced by any WSDL document”, and so on. Queries are executed against a set of S-RAMP artifacts using the criteria provided and the result returned is a set of S-RAMP artifacts. Furthermore, all artifact types both concrete and abstract are eligible for use in the query expressions.

Specific request and response syntax for executing query requests is, however, binding specific. Details can be found in the relevant binding document(s) of this specification. This document covers the common features of an S-RAMP query, independent of their invocation syntax.

4.1 Query Dialect (XPath2) Context

Since the S-RAMP query model is based on XPath2 [XPATH], this specification defines a static context for the information available during static analysis of a query expression prior to its evaluation, as well as a dynamic context for the information available when the expression is evaluated.

Static analysis of query expressions is performed using the following static context:

Table 8: Static Context for S-RAMP Query Expressions

Component	Value
XPath 1.0 Compatibility Mode	False
Statically known namespaces	See Table 4: Prefixes and XML Namespaces Used in this Specification
Default element/type namespaces	http://docs.oasis-open.org/s-ramp/ns/s-ramp-v1.0
Default function namespace	http://docs.oasis-open.org/s-ramp/ns/s-ramp-v1.0
In-scope schema definitions	S-RAMP schemas are defined at https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=s-ramp. A copy is included in the Appendices of this document.
In-scope variables	Only the variables used in a template based query expression (typically applies to Stored Query)
Context item static type	element(http://docs.oasis-open.org/s-ramp/ns/s-ramp-v1.0, record)
Function signatures	Functions defined in XQuery 1.0 and XPath 2.0 Functions and Operators document[QUERYOPS], plus functions defined in Section Query Functions
Statically known collations	none
Default collation	http://www.w3.org/2005/xpath-functions/collation/codepoint
Base URI	`none`
Statically known documents	`none`
Statically known collections	`none`
Statically known default collection type	`none`

The following dynamic context defines the default values that are available during evaluation of an S-RAMP query expression:

Table 9: Dynamic Context for S-RAMP Query Expressions

Component	Value
context item	dynamic; node changes during evaluation of the expression
context position	`1`
context size	`1`
Variable values	`none`
Function implementations	function implementations are on a per-server basis
Current dateTime	date and time on server against which request is made
Implicit time zone	UTC+/-0
Available documents	`none`
Available collections	`none`
Default collection	“s-ramp”

The domain of an S-RAMP query is the structure of the data model defined by its schemas, using the Artifact Model and Artifact Type reference syntax described in Error! Reference source not found..

Additional features and limitations of S-RAMP query support:

Uses the XPath2 default Axis of ancestor / child
The XPath abbreviated paths listed below are not supported:

‘..’

XPath2 Node types are not supported

Comments, text and so on are not relevant in an S-RAMP query

4.2 Query Expression Predicates

The default namespace assumed in an S-RAMP query is http://docs.oasis-open.org/s-ramp/ns/s-ramp-v1.0. S-RAMP query expressions allow filtering of the path expression using XPath 2.0 predicates, in the form:

{path-expression}[{predicate}]

where:

{path-expression} = /s-ramp/{ArtifactModel}/{ArtifactType}

corresponds to the S-RAMP Artifact Model and Type reference syntax (see Table 5: Pre-Defined Artifact Type Models); and:

{predicate}

is an XPath2 predicate which conforms to the S-RAMP query grammar (see SectionQuery Grammar).

When evaluated, the predicate returns true or false, and thus filters the set of artifacts returned from the query. Predicates can use combinations of artifact properties, relationships and classifications. The predicate sets the context for evaluating the query, making it wider or narrower. If a query predicate uses a property which is not defined on an artifact instance whose scope is within the path-expression, then the predicate is false for that artifact and it is not returned from the query. Several examples follow:

Example 3: Query Expressions Using Properties

/s-ramp/xsd/XsdDocument[@someProperty]

o Returns XsdDocument artifact instances which have a generic property named “someProperty”.

/s-ramp/xsd/XsdDocument[@name = 'bob']

o Returns XsdDocument artifact instances that have an artifact name whose value is “bob”.

/s-ramp/serviceImplementation/ServiceInstance[@someProperty =‘high’]

o Returns ServiceInstance artifact instances having a generic property called someProperty whose value equals ‘high’.

o If the requested property is not defined on the artifact within the set of artifacts selected for search, then the predicate is false and that artifact is therefore not returned.

Example 4: Query Expression Using Relationships

/s-ramp/wsdl/WsdlDocument[includedXsds]

o Returns all the WsdlDocument artifact instance(s) representing WSDL documents for which the query predicate evaluates to a non-empty context. The context here consists of the targets of the includedXsds relationship; therefore any WsdlDocument artifact that has at least one includedXsds relationship is returned.

o If the relationship in the predicate is not defined on a given artifact within the set of artifacts selected for search, then the predicate expression is false and that artifact is not returned.

Example 5: Query Expressions Using Relationships and Properties

/s-ramp/wsdl/WsdlDocument[includedXsds[@someProperty=’true’]]

o Only WsdlDocument artifact instances corresponding to WSDL documents which have at least one includedXsds relationship instance, that has a property name of “someProperty”, whose value is “true” will be returned.

o If the relationship in the predicate is not defined on a given artifact whose scope is within the path expression, then the predicate evaluates to false and that artifact is not returned.

Example 6: Extended Artifacts

/s-ramp/ext/BpmnDocument[@name = ‘LoanApproval’]

Returns only BpmnDocument extended artifact instances named ‘LoanApproval’.

Example 7: Query Expressions Using Relationships as Sub-Artifact Sets

/s-ramp/wsdl/Message[@name=’PurchaseRequestMessage’]/part

o Returns all Part artifacts of the Message artifact named ‘PurchaseRequestMessage’.

4.3 Query Functions

S-RAMP defines a number of its own query functions in addition to using some already defined in XPath 2.0 [XPATH]. This includes functions that provide several useful simplifications associated with how an artifact is classified. These query functions use the following syntax:

s-ramp:{function-name}({artifact}, {category-value-1}, {category-value-2}, …)

Table 10: Query Functions Used in S-RAMP below lists the functions used in S-RAMP. Each of the examples for the classification-based functions it describes assumes the following conceptual OWL ontology:

· class color

o class red

o class white

· class taste

o class sour

o class sweet

o class spicy

where this ontology is used to classify a set of WsdlService artifact instances:

· name = ”Bread” classifiedBy = [“white”, “sweet”]

· name = ”Wine” classifiedBy = [“red”, “sweet”]

· name = ”Chili” classifiedBy = [“red”, “spicy"]

and each of the classifiedBy URI references to these will be abbreviated simply as the class name here for brevity:

Table 10: Query Functions Used in S-RAMP

Function	Descriptions & Examples
s-ramp:classifiedByAnyOf	Returns all artifact instances classified by at least one of the specified OWL URIs or their subtypes. Syntax: classifiedByAnyOf({artifact}, {classifiedBy_1}, {classifiedBy_2},…) Using the classification example setup preceding this table, this example returns all 3 WsdlService artifact instances: /s-ramp/wsdl/WsdlService[classifiedByAnyOf(., ‘taste’)] This example returns the Wine and Chili WsdlService artifact instances: /s-ramp/wsdl/WsdlService[classifiedByAnyOf(., ‘red’, ‘spicy’)]
s-ramp:classifiedByAllOf	Returns all artifact instances classified by every one of the specified OWL URIs or their subtypes. Syntax: classifiedByAllOf({artifact}, {classifiedBy_1}, {classifiedBy_2},…) This example returns all 3 WsdlService artifact instances: /s-ramp/wsdl/WsdlService[classifiedByAllOf(., ‘taste’)] This example returns only the Wine WsdlService artifact instance: /s-ramp/wsdl/WsdlService[classifiedByAllOf(., ‘red’, ‘sweet’)]
s-ramp:exactlyClassifiedByAnyOf	Returns all artifact instances classified by at least one of the specified OWL URIs. Subtypes are not considered: Syntax: exactlyclassifiedByAnyOf({artifact}, {classifiedBy_1}, {classifiedBy_2},…) This example returns none of the WsdlService artifact instances: /s-ramp/wsdl/WsdlService[exactlyClassifiedByAnyOf(., ‘taste’)] This example returns only the Wine and Chili WsdlService artifact instances: /s-ramp/wsdl/WsdlService[exactlyClassifiedByAnyOf(., ‘red’, ‘taste’)]
s-ramp:exactlyClassifiedByAllOf	Returns all artifact instances classified by every one of the specified OWL URIs. Subtypes are not considered: Syntax: exactlyclassifiedByAllOf({artifact}, {classifiedBy_1}, {classifiedBy_2},…) This example returns none of the WsdlService artifact instances: /s-ramp/wsdl/WsdlService[exactlyClassifiedByAllOf(., ‘taste’)] This example returns only the Wine WsdlService artifact instance: /s-ramp/wsdl/WsdlService[exactlyClassifiedByAllOf(., ‘red’, ‘sweet’)]
xp2:matches	This is the XPath 2.0 matches function, which returns an xsd:boolean indicating whether {value} of its first argument matches the regular {expression} that is its second argument. Syntax: matches( {value}, {expression} ) The expression may use wildcards, but only in the form ‘.’ This example returns all artifact instances (of any Artifact Type) from the Service Implementation Model, whose artifact name* matches “.account.“, and a user-defined version property whose value is ‘1’. /s-ramp/serviceImplementation[xp2:matches(@name, ‘.account. ‘) and @version = ’1’]
xp2:not	This is the XPath 2.0 “not” (negation) function, which accepts an xsd:boolean as its input and returns the inversion. Syntax: not( {boolean-expression} ) Within the context of the S-RAMP query language, this function can only be applied within the predicate, and the ‘boolean-expression’ is restricted to a property or relationship. This effectively addresses the use-case of searching for artifacts that do not have a given property or relationship. /s-ramp/core/Document[xp2:not(@user-property)] /s-ramp/wsdl/Part[xp2:not(element)] Note: to invert a property value, simply use the ‘!=’ operator rather than the ‘not’ function.

4.4 Query Grammar

This section describes the XPath2 based query grammar used in S-RAMP. It is based on a redacted subset of the XPath 2.0 grammar [XPATH].

QName ::=

[http://www.w3.org/TR/REC-xml-names/#NT-QName]

s-ramp query ::=

artifact -set

| artifact -set ‘[‘ predicate ‘] |

| artifact -set ‘[‘ predicate ‘]’ ‘/’ subartifact-set

artifact- set::=

location-path

location-path::=

/s-ramp

|/s-ramp/<artifact-model>

| /s-ramp/<artifact-model>/<artifact-type>

| //<artifact-model>

| //<artifact-type>

subartifact-set:: =

relationship-path

| relationship-path ‘[‘ predicate ‘]’

| relationship-path ‘[‘ predicate ‘]’ ‘/’ subartifact-set

| FunctionCall

relationship-path::=

any-outgoing-relationship

| <s-ramp-relationship-type>

any-outgoing-relationship::=

outgoing

Predicate::=

Expr

Expr::=

AndExpr

AndExpr::=

OrExpr

| AndExpr 'and' OrExpr

OrExpr::=

EqualityExpr

| OrExpr 'or' EqualityExpr

EqualityExpr::=

subartifact-set

| '(' Expr ')'

PropertyQName ::=

QName

PrimaryExpr ::=

Literal
| Number

|'$' <PropertyQName>

ForwardPropertyStep ::=

Subaartifact-set’/’@<PropertyQName>|@<PropertyQName>

FunctionCall ::=

FunctionName '(' ( Argument ( ',' Argument )* )? ')'

Argument ::=

PrimaryExpr

| Expr

Literal ::=

'"' [^"]* '"' | "'" [^']* "'"

Number ::=

Digits ('.' Digits?)? | '.' Digits

Digits ::=

[0-9]+

FunctionName ::=

QName – NodeType

NodeType ::=

'comment'

| 'text'

| 'processing-instruction'

| 'node'

4.5 Stored Queries

S-RAMP provides support for storing queries in the repository using the StoredQuery Artifact Type. This can be convenient because it allows quick execution of a frequently performed query. The syntax associated with creation, retrieval, update and deletion of a Stored Query is binding specific. Refer to the appropriate binding document of this specification for details.

The StoredQuery Artifact Type does NOT extend BaseArtifactType as do most other Artifact Types in S-RAMP, which means it is simpler and possesses only these built-in attributes:

queryName: The name of the Stored Query instance. This must be unique.
queryExpression: The specification of the query expression.

A StoredQuery MAY also contain a list of propertyName values. These are used to indicate to the server that the results returned from the execution of the query SHALL include values for those property names when they are present in the artifact instance(s) returned. This can be valuable in bindings that may not necessarily return the complete artifact in query results. The actual format of the query response is binding specific.

5 Conformance

5.1 Introduction

S-RAMP defines a data model and protocol for Service Repository implementations.

An implementation is not compliant with this specification if it fails to satisfy one or more of the MUST or REQUIRED level requirements defined herein.

The XML Schemas take precedence over the normative text within this specification that takes precedence over the S-RAMP XML Schema in the appendix of this document. The authoritative S-RAMP XML Schema is published at:

https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=s-ramp

This specification addresses the following aspects of conformance:

Data Model
Classification Systems
Query Model

5.2 Data Model

A conformant implementation MUST include support for the following data models defined in Section 2 of this specification:

Note: "M" means mandatory-to-implement. "O" means optional.

Table 11: Required Data Models

Data Model	M/O
Core Model: Document	M
Core Model: XmlDocument	M
Extended Model: ExtendedArtifactType	M
Extended Model: ExtendedDocument	M
XSD Model: XsdDocument	M
XSD Model: ElementDeclaration	M
XSD Model: AttributeDeclaration	M
XSD Model: ComplexTypeDeclaration	M
XSD Model: SimpleTypeDeclaration	M
WSDL Model: WsdlDocument	M
WSDL Model: WsdlService	M
WSDL Model: Port	M
WSDL Model: Binding	M
WSDL Model: PortType	M
WSDL Model: BindingOperation	M
WSDL Model: BindingOperationInput	M
WSDL Model: BindingOperationFault	M
WSDL Model: BindingOperationOutput	M
WSDL Model: Operation	M
WSDL Model: OperationInput	M
WSDL Model: OperationOutput	M
WSDL Model: Fault	M
WSDL Model: Message	M
WSDL Model: Part	M
WSDL Model: WsdlExtension	O
SOAP WSDL Model: SoapAddress	M
SOAP WSDL Model: SoapBinding	M
Policy Model: PolicyDocument	M
Policy Model: PolicyAttachment	M
Policy Model: PolicyExpression	M
SOA Model: SoaModelType	M
SOA Model: ServiceInterface	M
SOA Model: Effect	M
SOA Model: Event	M
SOA Model: InformationType	M
SOA Model: Policy	M
SOA Model: PolicySubject	M
SOA Model: ServiceContract	M
SOA Model: Element	M
SOA Model: Service	M
SOA Model: Actor	M
SOA Model: Organization	M
SOA Model: System	M
SOA Model: Task	M
SOA Model: Composition	M
SOA Model: ServiceComposition	M
SOA Model: Choreography	M
SOA Model: Collaboration	M
SOA Model: Orchestration	M
SOA Model: Process	M
SOA Model: ChoreographyProcess	M
SOA Model: CollaborationProcess	M
SOA Model: OrchestrationProcess	M
Service Implementation Model: ServiceImplementationModelType	M
Service Implementation Model: ServiceInstance	M
Service Implementation Model: ServiceOperation	M
Service Implementation Model: ServiceEndpoint	M
Service Implementation Model: ServiceOperation	M

5.3 Classification Systems

A conformant implementation MAY support OWL Lite classification systems as defined in Classification Systems in S-RAMP of this specification. If an implementation chooses not to support OWL Lite classification systems, then it MUST fail if a value is added to the ‘classifiedBy’ attribute as defined in Classifications.

5.4 Query Model

S-RAMP defines an XPath 2 based query model. The following table lists the features of the S-RAMP Query Model and their conformance requirement:

Note: "M" means mandatory-to-implement. "O" means optional.

Query Model Feature	Example	M/O
All Artifact Query	/s-ramp	M
Filter by Artifact Model	/s-ramp/wsdl	M
Filter by Artifact Type	//ElementDeclaration	M
Filter by Both	/s-ramp/policy/PolicyAttachment	M
Filter by Core Attribute	//ElementDeclaration[@version=’1.0’]	M
Filter by Custom Attribute	//ElementDeclaration[@foo=’bar’]	M
Filter by Relationship	//ElementDeclaration[includedXsds]	M
Filter by Relationship Target	//Part[includedXsds[@name=’xyz.xsd’]]	M
Negation by Attribute	//ElementDeclaration[not(@foo)]	M
Negation by Relationship	//Part[not(element)]	M
Function: matches()	//Part[xp2:matches(@name, ‘foo.*’)	M
Function: s-ramp:classifiedByAnyOf	//Document[s-ramp:classifiedByAnyOf(., ‘spicy’)]	O
Function: s-ramp:classifiedByAllOf	//Document[s-ramp:classifiedByAllOf(., ‘spicy’)]	O
Function: s-ramp:exactlyClassifiedByAnyOf	//Document[s-ramp:exactlyClassifiedByAnyOf(., ‘spicy’)]	O
Function: s-ramp:exactlyClassifiedByAllOf	//Document[s-ramp:exactlyClassifiedByAllOf(., ‘spicy’)]	O
Boolean Filters	//Part[@name=’invoice’ and @prop1=’val1’]	M
Sub-Artifact Sets	//Message[@name=’customer’]/part	O

Appendix A. Acknowledgments

The following individuals have participated in the creation of this specification and are gratefully acknowledged:

Participants:

Joel Fleck II, Hewlett-Packard

Jishnu Mukerji, Hewlett-Packard

Radek Pospisil, Hewlett-Packard

Vincent Brunssen, IBM

John Colgrave, IBM

Diane Jordan, IBM

Bernard Kufluk, IBM

Kelvin Lawrence, IBM

Martin Smithson, IBM

Gershon Janssen, Individual

Carl Mattocks, Individual

Rex Brooks, Network Centric Operations Industry Consortium

jian zhang, Primeton Technologies, Inc.

Randall Hauch, Red Hat

Kurt Stam, Red Hat

Eric Wittmann, Red Hat

Steve Fanshier, Software AG, Inc.

Gary Woods, Software AG, Inc.

Prasad Yendluri, Software AG, Inc.

Eric Johnson, TIBCO Software Inc.

Senaka Fernando, WSO2

Paul Fremantle, WSO2

Jonathan Marsh, WSO2

Appendix B. Non-Normative Text

This specification provides no additional non-normative information at this time. It is expected that best practices for S-RAMP Repositories will emerge over time as this specification is adopted by vendors and users.

Appendix C. Revision History

Revision	Date	Editor	Changes Made
01	2012-11-30	Kurt Stam	S-RAMP JIRA issues 1, 18
02	2012-11-30	Eric Wittmann	S-RAMP JIRA issue 45
03	2012-12-01	Eric Wittmann	S-RAMP JIRA issue 38
04	2012-12-04	Eric Wittmann	S-RAMP JIRA issue 2
05	2012-12-04	Eric Wittmann	S-RAMP JIRA issue 15
06	2012-12-04	Eric Wittmann	S-RAMP JIRA issue 25
07	2013-01-09	Eric Wittmann	S-RAMP JIRA issue 46
08	2013-01-24	Eric Wittmann	S-RAMP JIRA issues 30, 40, 41
09	2013-02-04	Eric Wittmann	Update document to latest OASIS template
10	2013-02-11	Eric Wittmann	Added conformance section (Section 5) – S-RAMP JIRA issue 27
11	2013-02-18	Eric Wittmann	Changes based on review of the Foundation document, preparing for submission.
12	2013-02-20	Kurt Stam	Updated S-RAMP figures with latest generated from XMLSpy.
13	2013-02-20	Eric Wittmann	S-RAMP JIRA issue 48, namespace find/replace.
14	2013-03-06	Eric Wittmann	Negation support in the S-RAMP Query Language
15	2013-03-12	Kurt Stam	S-RAMP JIRA issue 51, Adding ExtendedDocument

Appendix D. Glossary

Term	Definition
Artifact Type	The data type of an S-RAMP artifact.
Artifact Type Model	Grouping of similar S-RAMP Artifact Types (e.g. wsdl, policy).
Service Implementation Model	Set of S-RAMP Artifact Types and relationships that describe the service implementation layer associated with the SOA Model.
Core Model	Set of basic Artifact Types.
Policy Model	Set of Policy document related derived Artifact Types.
Relationship	The logical triple of a Relationship Type, Source and Target. Relationships in S-RAMP are all directed from a source, to a target.
Relationship Type	A name that represents the type of the relationship (e.g., “includedXsds”). Multiple relationships can share the same Relationship Type.
SOA Model	Set of Artifact Types and relationships used to link The Open Group’s SOA Ontology artifact types with those in the S-RAMP data model.
WSDL Model	Set of WSDL document related derived data types.
XSD Model	Set of XSD document related derived data types.
Extended Artifact Model	An S-RAMP model whose content and structure has been defined by the client.

Appendix E. Core Model Schema

The S-RAMP Core Model Schema XSD file is also provided at:

http://docs.oasis-open.org/s-ramp/ns/s-ramp-v1.0/

<?xml version="1.0" encoding="UTF-8"?>

<xsd:schema targetNamespace="http://docs.oasis-open.org/s-ramp/ns/s-ramp-v1.0" version="1.0" xmlns:tns="http://docs.oasis-open.org/s-ramp/ns/s-ramp-v1.0" xmlns:s-ramp="http://docs.oasis-open.org/s-ramp/ns/s-ramp-v1.0"

xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xlink="http://www.w3.org/1999/xlink" elementFormDefault="qualified">

<!--

Corporation (IBM), Software AG (SAG) and TIBCO Software Inc. All

rights reserved. Permission to copy and display the SOA Repository

Artifact Model and Protocol (the “Specification”), in any medium

without fee or royalty is hereby granted by Hewlett-Packard Company

(HP), International Business Machines Corporation (IBM), Software AG

(SAG) and TIBCO Software Inc. (collectively, the "Authors"), provided

that you include the following on ALL copies of this document or

portions thereof, that you make:

1. A link or URL to this document at this location:

http://s-ramp.org/2010/s-ramp/specification/documents/{this document

name}

2. The copyright notice as shown in the Specification.

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 "SOA

Repository Artifact Model and Protocol” Specification, including all

its constituent documents. THIS 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 THIS 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 THIS DOCUMENT.

-->

<xsd:import namespace="http://www.w3.org/1999/xlink" schemaLocation="xlink.xsd" />

<xsd:simpleType name="baseArtifactEnum">

<xsd:restriction base="xsd:string">

<xsd:enumeration value="BaseArtifactType" />

<xsd:enumeration value="DocumentArtifactType" />

<xsd:enumeration value="Document" />

<xsd:enumeration value="XmlDocument" />

<xsd:enumeration value="XsdDocument" />

<xsd:enumeration value="WsdlDocument" />

<xsd:enumeration value="PolicyDocument" />

<xsd:enumeration value="DerivedArtifactType" />

<xsd:enumeration value="PolicyAttachment" />

<xsd:enumeration value="PolicyExpression" />

<xsd:enumeration value="AttributeDeclaration" />

<xsd:enumeration value="ElementDeclaration" />

<xsd:enumeration value="XsdType" />

<xsd:enumeration value="ComplexTypeDeclaration" />

<xsd:enumeration value="SimpleTypeDeclaration" />

<xsd:enumeration value="WsdlDerivedArtifactType" />

<xsd:enumeration value="NamedWsdlDerivedArtifactType" />

<xsd:enumeration value="WsdlService" />

<xsd:enumeration value="Port" />

<xsd:enumeration value="Binding" />

<xsd:enumeration value="PortType" />

<xsd:enumeration value="BindingOperation" />

<xsd:enumeration value="BindingOperationInput" />

<xsd:enumeration value="BindingOperationFault" />

<xsd:enumeration value="Operation" />

<xsd:enumeration value="OperationInput" />

<xsd:enumeration value="Fault" />

<xsd:enumeration value="Message" />

<xsd:enumeration value="Part" />

<xsd:enumeration value="BindingOperationOutput" />

<xsd:enumeration value="OperationOutput" />

<xsd:enumeration value="WsdlExtension" />

<xsd:enumeration value="SoapAddress" />

<xsd:enumeration value="SoapBinding" />

<xsd:enumeration value="ExtendedArtifactType" />

<xsd:enumeration value="ExtendedDocument" />

<xsd:enumeration value="SoaModelType" />

<xsd:enumeration value="ServiceInterface" />

<xsd:enumeration value="Effect" />

<xsd:enumeration value="Event" />

<xsd:enumeration value="InformationType" />

<xsd:enumeration value="Policy" />

<xsd:enumeration value="PolicySubject" />

<xsd:enumeration value="ServiceContract" />

<xsd:enumeration value="Element" />

<xsd:enumeration value="Service" />

<xsd:enumeration value="Actor" />

<xsd:enumeration value="Organization" />

<xsd:enumeration value="System" />

<xsd:enumeration value="Task" />

<xsd:enumeration value="Composition" />

<xsd:enumeration value="ServiceComposition" />

<xsd:enumeration value="Choreography" />

<xsd:enumeration value="Collaboration" />

<xsd:enumeration value="Orchestration" />

<xsd:enumeration value="Process" />

<xsd:enumeration value="ChoreographyProcess" />

<xsd:enumeration value="CollaborationProcess" />

<xsd:enumeration value="OrchestrationProcess" />

<xsd:enumeration value="ServiceImplementationModelType" />

<xsd:enumeration value="ServiceInstance" />

<xsd:enumeration value="ServiceOperation" />

<xsd:enumeration value="ServiceEndpoint" />

<xsd:enumeration value="ServiceOperation" />

</xsd:restriction>

</xsd:simpleType>

<xsd:simpleType name="derivedArtifactEnum">

<xsd:restriction base="s-ramp:baseArtifactEnum">

<xsd:enumeration value="DerivedArtifactType" />

<xsd:enumeration value="PolicyAttachment" />

<xsd:enumeration value="PolicyExpression" />

<xsd:enumeration value="AttributeDeclaration" />

<xsd:enumeration value="ElementDeclaration" />

<xsd:enumeration value="XsdType" />

<xsd:enumeration value="ComplexTypeDeclaration" />

<xsd:enumeration value="SimpleTypeDeclaration" />

<xsd:enumeration value="WsdlDerivedArtifactType" />

<xsd:enumeration value="NamedWsdlDerivedArtifactType" />

<xsd:enumeration value="WsdlService" />

<xsd:enumeration value="Port" />

<xsd:enumeration value="Binding" />

<xsd:enumeration value="PortType" />

<xsd:enumeration value="BindingOperation" />

<xsd:enumeration value="BindingOperationInput" />

<xsd:enumeration value="BindingOperationFault" />

<xsd:enumeration value="Operation" />

<xsd:enumeration value="OperationInput" />

<xsd:enumeration value="Fault" />

<xsd:enumeration value="Message" />

<xsd:enumeration value="Part" />

<xsd:enumeration value="BindingOperationOutput" />

<xsd:enumeration value="OperationOutput" />

<xsd:enumeration value="WsdlExtension" />

<xsd:enumeration value="SoapAddress" />

<xsd:enumeration value="SoapBinding" />

</xsd:restriction>

</xsd:simpleType>

<xsd:simpleType name="documentArtifactEnum">

<xsd:restriction base="s-ramp:baseArtifactEnum">

<xsd:enumeration value="DocumentArtifactType" />

<xsd:enumeration value="Document" />

<xsd:enumeration value="XmlDocument" />

<xsd:enumeration value="ExtendedDocument" />

<xsd:enumeration value="XsdDocument" />

<xsd:enumeration value="WsdlDocument" />

<xsd:enumeration value="PolicyDocument" />

</xsd:restriction>

</xsd:simpleType>

<xsd:complexType abstract="true" name="BaseArtifactType">

<xsd:sequence>

<xsd:element ref="tns:classifiedBy" minOccurs="0" maxOccurs="unbounded" />

<xsd:element ref="tns:relationship" minOccurs="0" maxOccurs="unbounded" />

<xsd:element ref="tns:property" minOccurs="0" maxOccurs="unbounded" />

</xsd:sequence>

<xsd:attribute name="artifactType" type="s-ramp:baseArtifactEnum" use="required" />

<xsd:attribute name="name" type="xsd:string" use="required" />

<xsd:attribute name="description" type="xsd:string" use="optional" />

<xsd:attribute name="createdBy" type="xsd:string" use="required" />

<xsd:attribute name="version" type="xsd:string" use="optional" />

<xsd:attribute name="uuid" type="xsd:string" use="required" />

<xsd:attribute name="createdTimestamp" type="xsd:dateTime" use="required" />

<xsd:attribute name="lastModifiedTimestamp" type="xsd:dateTime" use="required" />

<xsd:attribute name="lastModifiedBy" type="xsd:string" use="required" />

<xsd:anyAttribute namespace="##any" />

</xsd:complexType>

<xsd:complexType abstract="true" name="DerivedArtifactType">

<xsd:complexContent>

<xsd:extension base="s-ramp:BaseArtifactType">

<xsd:sequence>

<xsd:element name="relatedDocument" type="tns:documentArtifactTarget" minOccurs="1" maxOccurs="1" />

</xsd:sequence>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

<xsd:element name="DerivedArtifactType" type="tns:DerivedArtifactType" />

<xsd:complexType abstract="true" name="DocumentArtifactType">

<xsd:complexContent>

<xsd:extension base="s-ramp:BaseArtifactType">

<xsd:attribute name="contentType" type="xsd:string" />

<xsd:attribute name="contentSize" type="xsd:long" />

<xsd:attribute name="contentHash" type="xsd:string" />

<xsd:anyAttribute namespace="##any" />

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

<xsd:complexType name="Document">

<xsd:complexContent>

<xsd:extension base="s-ramp:DocumentArtifactType" />

</xsd:complexContent>

</xsd:complexType>

<xsd:complexType name="XmlDocument">

<xsd:complexContent>

<xsd:extension base="s-ramp:DocumentArtifactType">

<xsd:attribute name="contentEncoding" type="xsd:string" />

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

<xsd:complexType name="ExtendedArtifactType">

<xsd:complexContent>

<xsd:extension base="s-ramp:BaseArtifactType">

<xsd:attribute name="extendedType" type="xsd:string" />

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

<xsd:complexType name="ExtendedDocument">

<xsd:complexContent>

<xsd:extension base="s-ramp:DocumentArtifactType">

<xsd:attribute name="extendedType" type="xsd:string" />

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

<xsd:complexType name="target">

<xsd:simpleContent>

<xsd:extension base="xsd:string">

<xsd:attribute ref="xlink:href" use="required" />

<xsd:anyAttribute namespace="##any" />

</xsd:extension>

</xsd:simpleContent>

</xsd:complexType>

<xsd:complexType name="baseArtifactTarget">

<xsd:complexContent>

<xsd:extension base="s-ramp:target">

<xsd:attribute name="artifactType" type="s-ramp:baseArtifactEnum" use="required" />

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

<xsd:complexType name="derivedArtifactTarget">

<xsd:complexContent>

<xsd:extension base="s-ramp:target">

<xsd:attribute name="artifactType" type="s-ramp:derivedArtifactEnum" use="required" />

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

<xsd:complexType name="documentArtifactTarget">

<xsd:complexContent>

<xsd:extension base="s-ramp:target">

<xsd:attribute name="artifactType" type="s-ramp:documentArtifactEnum" use="required" />

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

<xsd:element name="relationship">

<xsd:complexType>

<xsd:sequence>

<xsd:element ref="tns:relationshipType" minOccurs="1" maxOccurs="1" />

<xsd:element name="relationshipTarget" type="tns:target" minOccurs="0" maxOccurs="unbounded" />

</xsd:sequence>

<xsd:anyAttribute namespace="##any" />

</xsd:complexType>

</xsd:element>

<xsd:element name="StoredQuery">

<xsd:complexType>

<xsd:sequence>

<xsd:element ref="tns:propertyName" minOccurs="0" maxOccurs="unbounded" />

<xsd:element ref="tns:queryExpression" />

</xsd:sequence>

<xsd:attribute name="queryName" type="xsd:string" />

<xsd:anyAttribute namespace="##any" />

</xsd:complexType>

</xsd:element>

<xsd:element name="property">

<xsd:complexType>

<xsd:sequence>

<xsd:element ref="tns:propertyName" minOccurs="1" maxOccurs="1" />

<xsd:element ref="tns:propertyValue" minOccurs="1" maxOccurs="1" />

</xsd:sequence>

<xsd:anyAttribute namespace="##any" />

</xsd:complexType>

</xsd:element>

<xsd:element name="relationshipType" type="xsd:string" />

<xsd:element name="classifiedBy" type="xsd:anyURI" />

<xsd:element name="propertyName" type="xsd:string" />

<xsd:element name="propertyValue" type="xsd:string" />

<xsd:element name="queryExpression" type="xsd:string" />

<xsd:element name="sourceId" type="xsd:string" />

<xsd:element name="targetId" type="xsd:string" />

</xsd:schema>

Appendix F. SOA Model Schema

The S-RAMP SOA Model Schema XSD file is also provided at:

http://docs.oasis-open.org/s-ramp/ns/s-ramp-v1.0/

<?xml version="1.0" encoding="UTF-8"?>

<xsd:schema xmlns:tns="http://docs.oasis-open.org/s-ramp/ns/s-ramp-v1.0" xmlns:s-ramp="http://docs.oasis-open.org/s-ramp/ns/s-ramp-v1.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema"

targetNamespace="http://docs.oasis-open.org/s-ramp/ns/s-ramp-v1.0" elementFormDefault="qualified" version="1.0">