OASIS ebXML RegRep Version 4.

0
Part 2: Services and Protocols (ebRS)
OASIS Standard
25 January 2012
Specification URIs
This version:
http://docs.oasis-open.org/regrep/regrep-core/v4.0/os/regrep-core-rs-v4.0-os.odt (Authoritative)
http://docs.oasis-open.org/regrep/regrep-core/v4.0/os/regrep-core-rs-v4.0-os.html
http://docs.oasis-open.org/regrep/regrep-core/v4.0/os/regrep-core-rs-v4.0-os.pdf
Previous version:
http://docs.oasis-open.org/regrep/regrep-core/v4.0/csd01/regrep-core-rs-v4.0-csd01.odt
(Authoritative)
http://docs.oasis-open.org/regrep/regrep-core/v4.0/csd01/regrep-core-rs-v4.0-csd01.html
http://docs.oasis-open.org/regrep/regrep-core/v4.0/csd01/regrep-core-rs-v4.0-csd01.pdf
Latest version:
http://docs.oasis-open.org/regrep/regrep-core/v4.0/regrep-core-rs-v4.0.odt (Authoritative)
http://docs.oasis-open.org/regrep/regrep-core/v4.0/regrep-core-rs-v4.0.html
http://docs.oasis-open.org/regrep/regrep-core/v4.0/regrep-core-rs-v4.0.pdf
Technical Committee:
OASIS ebXML Registry TC

Chairs:
Kathryn Breininger ([email protected]), Boeing
Farrukh Najmi ([email protected]), Wellfleet Software
Editors:
Farrukh Najmi, ([email protected]), Wellfleet Software
Nikola Stojanovic ([email protected]), Individual
Additional artifacts:
This specification consists of the following documents, schemas, and ontologies:
• Part 0: Overview Document - provides a global overview and description of the other parts
• Part 1: Registry Information Model (ebRIM) - specifies the types of metadata and content that
can be stored in an ebXML RegRep
• Part 2: Services and Protocols (ebRS) (this document) - specifies the services and protocols
for ebXML RegRep
• Part 3: XML Schema - specifies the XML Schema for ebXML RegRep
• Part 4: WSDL - specifies the WSDL interface descriptions for ebXML RegRep
• Part 5: XML Definitions - specifies the canonical XML data for ebXML RegRep as well as
example XML documents used in the specification

Related work:
This specification replaces or supersedes the OASIS ebXML RegRep 3.0 specifications.
Declared XML namespaces:
See Part 0: Overview Document.
regrep-core-rs-v4.0-os 25 January 2012
Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 1 of 95
Abstract:
This document defines the services and protocols for an ebXML RegRep.
A separate document, OASIS ebXML RegRep Version 4.0 Part 1: Registry Information Model
(ebRIM), defines the types of metadata and content that can be stored in an ebXML RegRep.

Status:
This document was last revised or approved by the OASIS ebXML Registry TC on the above
date. The level of approval is also listed above. Check the "Latest version" location noted above
for possible later revisions of this document.
Technical Committee members should send comments on this specification to the Technical
Committee's email list. Others should send comments to the Technical Committee by using the
"Send A Comment" button on the Technical Committee's web page at http://www.oasis-
open.org/committees/regrep/.
For information on whether any patents have been disclosed that may be essential to
implementing this specification, and any offers of patent licensing terms, please refer to the
Intellectual Property Rights section of the Technical Committee web page (http://www.oasis-
open.org/committees/regrep/ipr.php).

Citation format:
When referencing this specification the following citation format should be used:
[regrep-rs-v4.0]
OASIS ebXML RegRep Version 4.0 Part 2: Services and Protocols (ebRS). 25 January 2012.
OASIS Standard. http://docs.oasis-open.org/regrep/regrep-core/v4.0/os/regrep-core-rs-v4.0-
os.html.

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 2 of 95
Notices
Copyright © OASIS Open 2012. All Rights Reserved.
All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual
Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.
This document and translations of it may be copied and furnished to others, and derivative works that
comment on or otherwise explain it or assist in its implementation may be prepared, copied, published,
and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice
and this section are included on all such copies and derivative works. However, this document itself may
not be modified in any way, including by removing the copyright notice or references to OASIS, except as
needed for the purpose of developing any document or deliverable produced by an OASIS Technical
Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must
be followed) or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors
or assigns.
This document and the information contained herein is provided on an "AS IS" basis and OASIS
DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
OASIS requests that any OASIS Party or any other party that believes it has patent claims that would
necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard,
to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to
such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that
produced this specification.
OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of
any patent claims that would necessarily be infringed by implementations of this specification by a patent
holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR
Mode of the OASIS Technical Committee that produced this specification. OASIS may include such
claims on its website, but disclaims any obligation to do so.
OASIS takes no position regarding the validity or scope of any intellectual property or other rights that
might be claimed to pertain to the implementation or use of the technology described in this document or
the extent to which any license under such rights might or might not be available; neither does it represent
that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to
rights in any document or deliverable produced by an OASIS Technical Committee can be found on the
OASIS website. Copies of claims of rights made available for publication and any assurances of licenses
to be made available, or the result of an attempt made to obtain a general license or permission for the
use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS
Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any
information or list of intellectual property rights will at any time be complete, or that any claims in such list
are, in fact, Essential Claims.
The name "OASIS" is a trademark of OASIS, the owner and developer of this specification, and should be
used only to refer to the organization and its official outputs. OASIS welcomes reference to, and
implementation and use of, specifications, while reserving the right to enforce its marks against
misleading uses. Please see http://www.oasis-open.org/who/trademark.php for above guidance.

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 3 of 95
Table of Contents
1 Introduction............................................................................................................................................ 13
1.1 Terminology.................................................................................................................................... 13
1.2 Abstract Protocol............................................................................................................................ 13
1.2.1 RegistryRequestType.............................................................................................................. 13
1.2.1.1 Syntax............................................................................................................................ 13

1.2.1.2 Description..................................................................................................................... 13
1.2.2 RegistryResponseType........................................................................................................... 13
1.2.2.1 Syntax............................................................................................................................ 14

1.2.2.2 Description..................................................................................................................... 14
1.2.3 RegistryExceptionType........................................................................................................... 14
1.2.3.1 Syntax............................................................................................................................ 14

1.2.3.2 Description..................................................................................................................... 15
1.3 Server Plugins................................................................................................................................ 15
2 QueryManager Interface........................................................................................................................ 16
2.1 Parameterized Queries................................................................................................................... 16
2.1.1 Invoking Adhoc Queries.......................................................................................................... 16
2.2 Query Protocol................................................................................................................................ 16
2.2.1 QueryRequest......................................................................................................................... 16
2.2.1.1 Syntax............................................................................................................................ 17

2.2.1.2 Example......................................................................................................................... 17

2.2.1.3 Description..................................................................................................................... 17

2.2.1.4 Response....................................................................................................................... 18

2.2.1.5 Exceptions..................................................................................................................... 18
2.2.2 Element Query........................................................................................................................ 18
2.2.2.1 Syntax............................................................................................................................ 18

2.2.2.2 Description:.................................................................................................................... 19
2.2.3 Element ResponseOption........................................................................................................ 19
2.2.3.1 Syntax............................................................................................................................ 19

2.2.3.2 Description:.................................................................................................................... 19
2.2.4 QueryResponse...................................................................................................................... 20
2.2.4.1 Syntax............................................................................................................................ 20

2.2.4.2 Example......................................................................................................................... 20

2.2.4.3 Description:.................................................................................................................... 20

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 4 of 95
 2.2.5 Iterative Queries...................................................................................................................... 21
2.3 Parameterized Query Definition...................................................................................................... 21
2.4 Canonical Query: AdhocQuery....................................................................................................... 21
2.4.1 Parameter Summary............................................................................................................... 21
2.4.2 Query Semantics..................................................................................................................... 22
2.5 Canonical Query: BasicQuery........................................................................................................ 22
2.5.1 Parameter Summary............................................................................................................... 22
2.5.2 Query Semantics..................................................................................................................... 23
2.6 Canonical Query: ClassificationSchemeSelector............................................................................23
2.6.1 Parameter Summary............................................................................................................... 23
2.6.2 Query Semantics..................................................................................................................... 23
2.7 Canonical Query: FindAssociations................................................................................................23
2.7.1 Parameter Summary............................................................................................................... 24
2.7.2 Query Semantics..................................................................................................................... 24
2.8 Canonical Query: FindAssociatedObjects......................................................................................24
2.8.1 Parameter Summary............................................................................................................... 25
2.8.2 Query Semantics..................................................................................................................... 25
2.9 Canonical Query: GarbageCollector...............................................................................................26
2.9.1 Parameter Summary............................................................................................................... 26
2.9.2 Query Semantics..................................................................................................................... 26
2.10 Canonical Query: GetAuditTrailById.............................................................................................26
2.10.1 Parameter Summary............................................................................................................. 26
2.10.2 Query Semantics................................................................................................................... 27
2.11 Canonical Query: GetAuditTrailByLid...........................................................................................27
2.11.1 Parameter Summary............................................................................................................. 27
2.11.2 Query Semantics................................................................................................................... 27
2.12 Canonical Query: GetAuditTrailByTimeInterval............................................................................27
2.12.1 Parameter Summary............................................................................................................. 28
2.12.2 Query Semantics................................................................................................................... 28
2.13 Canonical Query: GetChildrenByParentId....................................................................................28
2.13.1 Parameter Summary............................................................................................................. 28
2.13.2 Query Semantics................................................................................................................... 29
2.14 Canonical Query: GetClassificationSchemesById........................................................................29
2.14.1 Parameter Summary............................................................................................................. 29
2.14.2 Query Semantics................................................................................................................... 30
2.15 Canonical Query: GetRegistryPackagesByMemberId..................................................................30
2.15.1 Parameter Summary............................................................................................................. 30
2.15.2 Query Semantics................................................................................................................... 30

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 5 of 95
 2.16 Canonical Query: GetNotification................................................................................................. 30
2.16.1 Parameter Summary............................................................................................................. 30
2.16.2 Query Semantics................................................................................................................... 31
2.17 Canonical Query: GetObjectById.................................................................................................. 31
2.17.1 Parameter Summary............................................................................................................. 31
2.17.2 Query Semantics................................................................................................................... 31
2.18 Canonical Query: GetObjectsByLid..............................................................................................31
2.18.1 Parameter Summary............................................................................................................. 31
2.18.2 Query Semantics................................................................................................................... 32
2.19 Canonical Query: GetReferencedObject......................................................................................32
2.19.1 Parameter Summary............................................................................................................. 32
2.19.2 Query Semantics................................................................................................................... 32
2.20 Canonical Query: KeywordSearch................................................................................................ 32
2.20.1 Canonical Indexes................................................................................................................. 32
2.20.2 Parameter Summary............................................................................................................. 33
2.20.3 Query Semantics................................................................................................................... 33
2.21 Canonical Query: RegistryPackageSelector.................................................................................34
2.21.1 Parameter Summary............................................................................................................. 34
2.21.2 Query Semantics................................................................................................................... 35
2.22 Query Functions........................................................................................................................... 35
2.22.1 Using Functions in Query Expressions..................................................................................35
2.22.2 Using Functions in Query Parameters...................................................................................36
2.22.3 Function Processing Model.................................................................................................. 36
2.22.4 Function Processor BNF....................................................................................................... 37
2.23 Common Patterns In Query Functions.........................................................................................38
2.23.1 Specifying a null Value for string Param or Return Value......................................................38
2.24 Canonical Functions..................................................................................................................... 38
2.24.1 Canonical Function: currentTime...........................................................................................39
2.24.1.1 Function Semantics..................................................................................................... 39
2.24.2 Canonical Function: currentUserId........................................................................................39
2.24.2.1 Function Semantics..................................................................................................... 39
2.24.3 Canonical Function: relativeTime..........................................................................................39
2.24.3.1 Parameter Summary.................................................................................................... 39

2.24.3.2 Function Semantics..................................................................................................... 39

2.24.4 Canonical Function: getClassificationNodes.........................................................................39
2.24.4.1 Parameter Summary.................................................................................................... 40

2.24.4.2 Function Semantics..................................................................................................... 40

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 6 of 95
 2.25 Query Plugins............................................................................................................................... 41
2.25.1 Query Plugin Interface........................................................................................................... 41
3 LifecycleManager Interface.................................................................................................................... 42
3.1 SubmitObjects Protocol.................................................................................................................. 42
3.1.1 SubmitObjectsRequest............................................................................................................ 42
3.1.1.1 Syntax............................................................................................................................ 42

3.1.1.2 Description..................................................................................................................... 43

3.1.1.3 id and lid Requirements................................................................................................. 43

3.1.1.4 Returns.......................................................................................................................... 44

3.1.1.5 Exceptions..................................................................................................................... 44
3.1.2 Audit Trail Requirements......................................................................................................... 44
3.1.3 Sample SubmitObjectsRequest............................................................................................... 45
3.2 The Update Objects Protocol.......................................................................................................... 45
3.2.1 UpdateObjectsRequest........................................................................................................... 45
3.2.1.1 Syntax............................................................................................................................ 46

3.2.1.2 Description..................................................................................................................... 46

3.2.1.3 Returns.......................................................................................................................... 47

3.2.1.4 Exceptions..................................................................................................................... 47
3.2.2 UpdateAction........................................................................................................................... 47
3.2.2.1 Syntax............................................................................................................................ 47

3.2.2.2 Description..................................................................................................................... 47
3.2.3 Audit Trail Requirements......................................................................................................... 48
3.2.4 Sample UpdateObjectsRequest..............................................................................................49
3.3 RemoveObjects Protocol................................................................................................................ 49
3.3.1 RemoveObjectsRequest......................................................................................................... 49
3.3.1.1 Syntax............................................................................................................................ 50

3.3.1.2 Description..................................................................................................................... 50

3.3.1.3 Returns:......................................................................................................................... 51

3.3.1.4 Exceptions:................................................................................................................... 51
3.3.2 Audit Trail Requirements......................................................................................................... 51
3.3.3 Sample RemoveObjectsRequest............................................................................................51
4 Version Control...................................................................................................................................... 52
4.1 Version Controlled Resources........................................................................................................ 52
4.2 Versioning and Id Attribute............................................................................................................. 53
4.3 Versioning and Lid Attribute............................................................................................................ 53
4.4 Version Identification for RegistryObjectType.................................................................................53
regrep-core-rs-v4.0-os 25 January 2012
Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 7 of 95
 4.5 Version Identification for RepositoryItem........................................................................................ 53
4.5.1 Versioning of RegistryObjectType........................................................................................... 53
4.5.2 Versioning of ExtrinsicObjectType...........................................................................................54
4.6 Versioning and References............................................................................................................ 54
4.7 Versioning of RegistryPackages..................................................................................................... 55
4.8 Versioning and RegistryPackage Membership...............................................................................55
4.9 Inter-version Association................................................................................................................ 55
4.10 Version Removal.......................................................................................................................... 55
4.11 Locking and Concurrent Modifications..........................................................................................56
4.12 Version Creation........................................................................................................................... 56
5 Validator Interface.................................................................................................................................. 57
5.1 ValidateObjects Protocol................................................................................................................ 57
5.1.1 ValidateObjectsRequest.......................................................................................................... 57
5.1.1.1 Syntax............................................................................................................................ 57

5.1.1.2 Example......................................................................................................................... 58

5.1.1.3 Description..................................................................................................................... 58

5.1.1.4 Response....................................................................................................................... 58

5.1.1.5 Exceptions..................................................................................................................... 58
5.1.2 ValidateObjectsResponse....................................................................................................... 58
5.2 Validator Plugins............................................................................................................................. 58
5.2.1 Validator Plugin Interface........................................................................................................ 59
5.2.2 Canonical XML Validator Plugin.............................................................................................. 59
6 Cataloger Interface................................................................................................................................ 60
6.1 CatalogObjects Protocol................................................................................................................. 60
6.1.1 CatalogObjectsRequest.......................................................................................................... 60
6.1.1.1 Syntax............................................................................................................................ 60

6.1.1.2 Example......................................................................................................................... 61

6.1.1.3 Description..................................................................................................................... 61

6.1.1.4 Response....................................................................................................................... 61

6.1.1.5 Exceptions..................................................................................................................... 61
6.1.2 CatalogObjectsResponse........................................................................................................ 61
6.1.2.1 Syntax............................................................................................................................ 62

6.1.2.2 Example......................................................................................................................... 62

6.1.2.3 Description..................................................................................................................... 62
6.2 Cataloger Plugins........................................................................................................................... 63
6.2.1 Cataloger Plugin Interface....................................................................................................... 63

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 8 of 95
 6.2.2 Canonical XML Cataloger Plugin............................................................................................. 63
7 Subscription and Notification................................................................................................................. 65
7.1 Server Events................................................................................................................................. 65
7.1.1 Pruning of Events.................................................................................................................... 65
7.2 Notifications.................................................................................................................................... 65
7.3 Creating a Subscription.................................................................................................................. 65
7.3.1 Subscription Authorization....................................................................................................... 65
7.3.2 Subscription Quotas................................................................................................................ 65
7.3.3 Subscription Expiration............................................................................................................ 66
7.3.4 Event Selection....................................................................................................................... 66
7.4 Event Delivery................................................................................................................................ 67
7.4.1 Notification Option................................................................................................................... 67
7.4.2 Delivery to NotificationListener Web Service...........................................................................67
7.4.3 Delivery to Email Address....................................................................................................... 67
7.4.4 Delivery to a NotificationListener Plugin..................................................................................67
7.4.4.1 Processing Email Notification Via XSLT........................................................................67
7.5 NotificationListener Interface.......................................................................................................... 67
7.6 Notification Protocol........................................................................................................................ 68
7.6.1 Notification............................................................................................................................... 68
7.7 Pulling Notification on Demand....................................................................................................... 68
7.8 Deleting a Subscription................................................................................................................... 68
8 Multi-Server Features............................................................................................................................ 69
8.1 Remote Objects Reference............................................................................................................ 69
8.2 Local Replication of Remote Objects..............................................................................................69
8.2.1 Creating Local Replica and Keeping it Synchronized..............................................................70
8.2.2 Removing a Local Replica....................................................................................................... 71
8.2.3 Removing Subscription With Remote Server..........................................................................71
8.3 Registry Federations....................................................................................................................... 71
8.3.1 Federation Configuration......................................................................................................... 72
8.3.1.1 Creating a Federation.................................................................................................... 72

8.3.1.2 Joining a Federation...................................................................................................... 72

8.3.1.3 Leaving a Federation..................................................................................................... 73

8.3.1.4 Dissolving a Federation.................................................................................................73

8.3.2 Local Vs. Federated Queries................................................................................................... 73
8.3.2.1 Local Queries................................................................................................................. 73

8.3.2.2 Federated Queries......................................................................................................... 73

8.3.3 Local Replication of Federation Configuration.........................................................................74

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 9 of 95
 8.3.4 Time Synchronization Between Federation Members.............................................................74
9 Governance Features............................................................................................................................ 75
9.1 Representing a Governance Collaboration ....................................................................................75
9.1.1 Content of Governance Collaboration BPMN Files.................................................................77
9.2 Scope of Governance Collaborations.............................................................................................77
9.2.1 Packaging Related Objects as a Governance Unit..................................................................77
9.3 Assigning a Governance Collaboration...........................................................................................78
9.4 Determining Applicable Governance Collaboration........................................................................78
9.5 Determining the Registry Process in a Governance Collaboration.................................................78
9.6 Starting the Registry Process for a Governance Collaboration.......................................................79
9.6.1 Starting Registry Process By WorkflowAction.........................................................................79
9.7 Incoming messageFlows to Registry Process................................................................................79
9.8 Outgoing messageFlows from Registry Process............................................................................79
9.9 Canonical Task Patterns................................................................................................................. 79
9.9.1 SendWorkflowAction Task Pattern.......................................................................................... 80
9.9.1.1 Server Processing of WorkflowAction............................................................................80
9.9.2 ReceiveWorkflowAction Task Pattern.....................................................................................81
9.9.3 SendNotification Task Pattern.................................................................................................81
9.9.4 ReceiveNotification Task Pattern............................................................................................82
9.9.5 SetStatus Task........................................................................................................................ 82
9.9.6 Validate Task........................................................................................................................... 82
9.9.7 Catalog Task........................................................................................................................... 82
9.10 XPATH Extension Functions........................................................................................................ 83
9.11 Default Governance Collaboration................................................................................................ 83
10 Security Features................................................................................................................................. 85
10.1 Message Integrity......................................................................................................................... 85
10.1.1 Transport Layer Security....................................................................................................... 85
10.1.2 SOAP Message Security....................................................................................................... 85
10.2 Message Confidentiality................................................................................................................ 86
10.3 User Registration and Identity Management.................................................................................86
10.4 Authentication............................................................................................................................... 86
10.5 Authorization and Access Control................................................................................................. 86
10.6 Audit Trail..................................................................................................................................... 86
11 Native Language Support (NLS).......................................................................................................... 87
11.1 Terminology.................................................................................................................................. 87
11.2 NLS and Registry Protocol Messages..........................................................................................87
11.3 NLS Support in RegistryObjects .................................................................................................. 87
11.3.1 Language of a LocalizedString .............................................................................................88
regrep-core-rs-v4.0-os 25 January 2012
Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 10 of 95
 11.3.2 Character Set of RegistryObject ...........................................................................................88
11.4 NLS and Repository Items ........................................................................................................... 89
11.4.1 Character Set of Repository Items........................................................................................ 89
11.4.2 Language of Repository Items............................................................................................... 89
12 REST Binding...................................................................................................................................... 90
12.1 Canonical URL............................................................................................................................. 90
12.1.1 Canonical URL for RegistryObjects.......................................................................................90
12.1.2 Canonical URL for Repository Items.....................................................................................90
12.2 Query Protocol REST Binding...................................................................................................... 91
12.2.1 Parameter queryId................................................................................................................. 91
12.2.2 Query Specific Parameters.................................................................................................... 91
12.2.3 Canonical Query Parameter: depth.......................................................................................91
12.2.4 Canonical Query Parameter: format......................................................................................92
12.2.5 Canonical Query Parameter: federated.................................................................................92
12.2.6 Canonical Query Parameter: federation................................................................................92
12.2.7 Canonical Query Parameter: matchOlderVersions................................................................92
12.2.8 Canonical Query Parameter: startIndex................................................................................92
12.2.9 Canonical Query Parameter: lang......................................................................................... 93
12.2.10 Canonical Query Parameter: maxResults...........................................................................93
12.2.11 Use of Functions in Query Parameters................................................................................93
12.2.12 Query Response................................................................................................................. 93
13 SOAP Binding...................................................................................................................................... 94
13.1 WS-Addressing SOAP Headers................................................................................................... 94
Appendix A. Protocol Exceptions.............................................................................................................. 95

Illustration Index
Illustration 1: Query Protocol...................................................................................................................... 16
Illustration 2: SubmitObjects Protocol........................................................................................................ 42
Illustration 3: UpdateObjects Protocol........................................................................................................ 45
Illustration 4: RemoveObjects Protocol...................................................................................................... 49
Illustration 5: A visual example of a version tree........................................................................................ 52
Illustration 6: ValidateObjects Protocol...................................................................................................... 57
Illustration 7: CatalogObjects Protocol....................................................................................................... 60
Illustration 8: Notification Protocol.............................................................................................................. 68
Illustration 9: Remote Object Reference.................................................................................................... 69
Illustration 10: Local Replication of Remote Objects..................................................................................70
Illustration 11: Registry Federations........................................................................................................... 72
Illustration 12: Default Governance Collaboration......................................................................................76

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 11 of 95
Index of Tables
Table 1: Canonical Functions Defined By This Profile...............................................................................38
Table 2: Requirements for id and lid During SubmitObjects Protocol........................................................44

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 12 of 95
 1 1 Introduction
2 All text is normative unless otherwise indicated.

3 This document specifies the ebXML RegRep service interfaces and the protocols they support. For a gen-
4 eral overview of ebXML RegRep and other related parts of the specification please refer to Part 0 [regrep-
5 overview-v4.0].

6 1.1 Terminology
7 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD
8 NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as de-
9 scribed in IETF [RFC 2119].

10 1.2 Abstract Protocol

11 This section describes the types RegistryRequestType, RegistryResponseType and RegistryException-
12 Type defined within rs.xsd that are the abstract types used by most protocols defined by this specification
13 in subsequent chapters. A typical registry protocol is initiated by a request message that extends Re-
14 gistryRequestType. In response the registry server sends a response that extends RegistryResponse-
15 Type. If an error is encountered by the server during the processing of a request, the server returns a fault
16 message that extends the RegistryExceptionType.

17 1.2.1 RegistryRequestType
18 The RegistryRequestType is the abstract base type for most requests sent by client to the server.

19 1.2.1.1 Syntax
<complexType name="RegistryRequestType">
<complexContent>
<extension base="rim:ExtensibleObjectType">
<attribute name="id" type="string" use="required"/>
<attribute name="comment" type="string" use="optional"/>
</extension>
</complexContent>
</complexType>

20 1.2.1.2 Description
21 ● Attribute comment – The comment attribute if specified contains a String that describes the re-
22 quest. A server MAY save this comment within a CommentType instance and associate it with
23 the AuditableEvent(s) for that request as described by [regrep-rim-v4.0].

24 ● Attribute id – The id attribute must be specified by the client to uniquely identify a request. Its
25 value SHOULD be a UUID URN like “urn:uuid:a2345678-1234-1234-123456789012”.

26 1.2.2 RegistryResponseType
27 The RegistryResponseType is the base type for most responses sent by the server to the client in re-
28 sponse to a client request. A global RegistryResponse element is defined using this type which is used by
29 several requests defined within this specification.
regrep-core-rs-v4.0-os 25 January 2012
Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 13 of 95
30 1.2.2.1 Syntax
<complexType name="RegistryResponseType">
<complexContent>
<extension base="rim:ExtensibleObjectType">
<sequence>
<element name="Exception" type="tns:RegistryExceptionType"
minOccurs="0" maxOccurs="unbounded"/>
<element ref="rim:RegistryObjectList" minOccurs="0" maxOccurs="1"/>
<element ref="rim:ObjectRefList" minOccurs="0" maxOccurs="1"/>
</sequence>
<attribute name="status" type="rim:objectReferenceType" use="required"/>
<attribute name="requestId" type="anyURI" use="optional"/>
</extension>
</complexContent>
</complexType>
<element name="RegistryResponse" type="tns:RegistryResponseType"/>

31 1.2.2.2 Description
32 ● Element ObjectRefList – Contains a sequence of zero or more RegistryObject elements. It is
33 used by requests that return

34 ● Element RegistryObjectList – Contains a sequence of zero or more ObjectRef elements. It is

35 used by requests that return a list of references to RegistryObject instances

36 ● Attribute requestId – This attribute contains the id of the request that returned this QueryRe-
37 sponse.

38 ● Attribute status – This attribute contains the status of the response. Its value MUST be a refer-
39 ence to a ClassificationNode within the canonical ResponseStatusType ClassificationScheme. A
40 server MUST support the status types as defined by the canonical ResponseStatusType Classi-
41 ficationScheme. The canonical ResponseStatusType ClassificationScheme may be extended by
42 adding additional ClassificationNodes to it.
43
44 The following canonical values are defined for the ResponseStatusType ClassificationScheme:

45 ○ Failure - This status specifies that the request encountered a failure. This value MUST never
46 be returned since a server MUST indicate failure conditions by returning an appropriate fault
47 message.

48 ○ PartialSuccess - This status specifies that the request was partially successful. Certain re-
49 quests such as federated queries allow this status to be returned.

50 ○ Success - This status specifies that the request was successful.

51 ○ Unavailable – This status specifies that the response is not yet available. This may be the
52 case if this RegistryResponseType represents an immediate response to an asynchronous
53 request where the actual response is not yet available.

54 1.2.3 RegistryExceptionType
55 The RegistryExceptionType is the abstract base type for all exception or fault messages sent by the
56 server to the client in response to a client request. A list of all protocol exceptions is available in the
57 Protocol Exceptions appendix.

58 1.2.3.1 Syntax
<complexType name="RegistryExceptionType">

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 14 of 95
 <annotation>
<documentation>Base for all registry exceptions. Based upon SOAPFault:
http://www.w3schools.com/soap/soap_fault.asp</documentation>
</annotation>
<complexContent>
<extension base="rim:ExtensibleObjectType">
<attribute name="code" type="string" use="optional"/>
<attribute name="detail" type="string" use="optional"/>
<attribute name="message" type="string"/>
<attribute name="severity" type="rim:objectReferenceType"
default="urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error"/>
</extension>
</complexContent>
</complexType>

59 1.2.3.2 Description
60 In addition to the attributes and elements inherited from ExtensibleObjectType this type defines the follow-
61 ing attributes and elements:

62 ● Attribute code – The code attribute value may be used by a server to provide an error code or
63 identifier for an Exception.

64 ● Attribute detail – The detail attribute value may be used by a server to provide any detailed in-
65 formation such as a stack trace for an Exception.

66 ● Attribute message – The message attribute value MUST be used by a server to provide a brief
67 message summarizing an Exception.

68 ● Attribute severity – The severity attribute value provides a severity level for the exception. Its
69 value SHOULD reference a ClassificationNode within the canonical ErrorSeverityType Classifica-
70 tionScheme.

71 1.3 Server Plugins

72 Deployments of a server MAY extend the core functionality of the server by using function-specific soft-
73 ware modules called plugins. A plugin extends the server by adding additional functionality to it. A plugin
74 MUST conform to standard interfaces as defined by this specification. These standard interfaces are re-
75 ferred to as Service Provider Interfaces (SPI).
76 Subsequent chapters will specifies various Service Provider Interfaces (SPI) that defines the standard in-
77 terface for various types of server plugins. These interfaces are described in form of [WSDL2, WSDL1]
78 specification.
79 A server may implement these interfaces as external web services invoked by the server using [SOAP-
80 MF, SOAP-ADJ] or as plugin modules that share the same process as the server and are invoked by local
81 function calls.
82 Examples of types of server plugins include, but are not limited to query plugin, validator plugin and cata-
83 loger plugin.
84 This specification does not define how a plugin is implemented or how it is configured within a server. Nor
85 does it define whether or how, plugin configuration functionality is made discoverable to clients.

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 15 of 95
 86 2 QueryManager Interface
87 The QueryManager interface allows a client to invoke queries on the server.

88 2.1 Parameterized Queries

89 A server may support any number of pre-configured queries known as Parameterized Queries, that may
90 be invoked by clients. Parameterized queries are similar in concept to stored procedures in SQL.

91 This specification defines a number of canonical queries that are standard queries that MUST be suppor-
92 ted by a server. Profiles, implementations and deployments may define additional parameterized queries
93 beyond the canonical queries defined by this specification.

94 A client invokes a parameterized query supported by the server by specifying its unique id as well as val-
95 ues for any parameters supported by the query.

96 A parameterized query MAY be stored in the server as a specialized RegistryObject called QueryDefini-
97 tion object which is defined by [regrep-rim-v4.0]. The definition of a QueryDefinition may contain any num-
98 ber of Parameters supported by the query.

99 2.1.1 Invoking Adhoc Queries

100 A client may invoke a client-specific ad hoc query using a special canonical parameterized query called
101 the AdhocQuery query defined by this specification. Due to the risks associated with un-controlled ad hoc
102 queries, a deployment MAY choose to restrict the invocation of the AdhocQuery query to specific roles.
103 This specification does not define a standard query expression syntax for ad hoc queries. A server MAY
104 support any number of query expression syntaxes for ad hoc queries.

105 2.2 Query Protocol

106 A client invokes a parameterized query using the Query protocol defined by the executeQuery operation
107 of the QueryManager interface.

108 A client initiates the Query protocol by sending a QueryRequest message to the QueryManager endpoint.

109 The QueryManager sends a QueryResponse back to the client as response. The QueryResponse con-
110 tains a set of objects that match the query.

Illustration 1: Query Protocol

112 2.2.1 QueryRequest

113 The QueryRequest message is sent by the client to the QueryManager interface to invoke a query.

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 16 of 95
114 2.2.1.1 Syntax
<element name="QueryRequest">
<complexType>
<complexContent>
<extension base="rs:RegistryRequestType">
<sequence>
<element name="ResponseOption" type="tns:ResponseOptionType"
minOccurs="1" maxOccurs="1"/>
<element name="Query" type="rim:QueryType"
minOccurs="1" maxOccurs="1" />
</sequence>
<attribute name="federated" type="boolean"
use="optional" default="false"/>
<attribute name="federation" type="anyURI" use="optional"/>
<attribute name="format" type="string"
use="optional" default="application/ebrim+xml"/>
<attribute ref="xml:lang" use="optional"/>
<attribute name="startIndex" type="integer" default="0"/>
<attribute name="maxResults" type="integer" default="-1"/>
<attribute name="depth" type="integer" default="0"/>
<attribute name="matchOlderVersions" type="boolean"
use="optional" default="false"/>
</extension>
</complexContent>
</complexType>
</element>

115 2.2.1.2 Example

116 The following example shows a QueryRequest which gets an object by its id using the canonical GetOb-
117 jectById query.

118
<query:QueryRequest maxResults="-1" startIndex="0" ...>
<rs:ResponseOption returnComposedObjects="true"
returnType="LeafClassWithRepositoryItem"/>
<query:Query queryDefinition="urn:oasis:names:tc:ebxml-
regrep:query:GetObjectById">
<rim:Slot name="id">
<rim:SlotValue xsi:type="StringValueType"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<rim:Value>%danyal%</rim:Value>
</rim:SlotValue>
</rim:Slot>
</query:Query>
</query:QueryRequest>

119 2.2.1.3 Description

120 ● Element ResponseOption - This required element allows the client to control the content of the
121 QueryResponse generated by the server in response to this request.

122 ● Element Query - This element identifies a parameterized query and supplies values for its para-
123 meters.

124 ● Attribute depth - This optional attribute specifies the pre-fetch depth of the response desired by
125 the client. A depth of 0 (default) indicates that the server MUST return only those objects that
126 match the query. A depth of N where N is greater that 0 indicates that the server MUST also re-
127 turn objects that are reachable by N levels of references via attributes that reference other ob-

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 17 of 95
128 jects. A depth of -1 indicates that the server MUST return all objects within the transitive closure
129 of all references from objects that matches the query.

130 ● Attribute federated – This optional attribute specifies that the server must process this query as a
131 federated query. By default its value is false. This value MUST be false when a server routes a
132 federated query to another server. This is to avoid an infinite loop in federated query processing.

133 ● Attribute federation - This optional attribute specifies the id of the target Federation for a feder-
134 ated query in case the server is a member of multiple federations. In the absence of this attribute
135 a server must route the federated query to all registries that are a member of all federations con-
136 figured within the local server. This value MUST be unspecified when a server routes a federated
137 query to another server. This is to avoid an infinite loop in federated query processing.

138 ● Attribute format - This optional attribute specifies the format of the response desired by the client.
139 The default value is “application/x-ebrs+xml” which returns the response in ebRS
140 QueryResponse format.

141 ● Attribute lang - This optional attribute specifies the natural language of the response desired by
142 the client. The default value is to return the response with all available natural languages.

143 ● Attribute matchOlderVersions – This optional attribute specifies the behavior when multiple ver-
144 sions of the same object are matched by a query. When the value of this attribute is specified as
145 false (the default) then a server MUST only return the latest matched version for any object and
146 MUST not return older versions of such objects even though they may match the query. When
147 the value of this attribute is specified as true then a server MUST return all matched versions of
148 all objects.

149 ● Attribute maxResults - This optional attribute specifies a limit on the maximum number of results
150 the client wishes the query to return. If unspecified, the server SHOULD return either all the res-
151 ults, or in case the result set size exceeds a server specific limit, the server SHOULD return a
152 sub-set of results that are within the bounds of the server specific limit. This attribute is described
153 further in the Iterative Queries section.

154 ● Attribute startIndex - This optional integer value is used to indicate which result must be returned
155 as the first result when iterating over a large result set. The default value is 0, which returns the
156 result set starting with index 0 (first result). This attribute is described further in the Iterative
157 Queries section.

158 2.2.1.4 Response

159 This request returns QueryResponse as response.

160 2.2.1.5 Exceptions

In addition to common exceptions, the following exceptions MAY be returned:

● QueryException: signifies that the query syntax or semantics was invalid. Client must fix the query syntax or
semantic error and re-submit the query

161 2.2.2 Element Query

162 A client specifies a Query element within a QueryRequest to specify the parameterized query being in-
163 voked as well as the values for its parameters.

164 2.2.2.1 Syntax

<complexType name="QueryType">
regrep-core-rs-v4.0-os 25 January 2012
Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 18 of 95
 <complexContent>
<extension base="tns:ExtensibleObjectType">
<attribute name="queryDefinition"
type="tns:objectReferenceType" use="required"/>
</extension>
</complexContent>
</complexType>
165

166 2.2.2.2 Description:

167 ● Element Slot - Each Slot element specifies a parameter value for a parameter supported by the
168 query. The slot name MUST match a parameterName attribute within a rim:Parameter definition
169 within the rim:QueryDefinition definition. The slot value provides a value for the parameter. Order
170 of parameters is not significant.

171 ● Attribute query - The value of this attribute must be a reference to a parameterized query that is
172 supported by the server.

173 2.2.3 Element ResponseOption

174 A client specifies a ResponseOption structure within a QueryRequest to control the type and structure of
175 results within the corresponding QueryResponse.

176 2.2.3.1 Syntax

<complexType name="ResponseOptionType">
<attribute name="returnType" default="LeafClassWithRepositoryItem">
<simpleType>
<restriction base="NCName">
<enumeration value="ObjectRef"/>
<enumeration value="RegistryObject"/>
<enumeration value="LeafClass"/>
<enumeration value="LeafClassWithRepositoryItem"/>
</restriction>
</simpleType>
</attribute>
<attribute name="returnComposedObjects"
type="boolean" use="optional" default="false"/>
</complexType>
<element name="ResponseOption" type="tns:ResponseOptionType"/>

177 2.2.3.2 Description:

178 ● Attribute returnComposedObjects - This optional attribute specifies whether the RegistryObjects
179 returned should include composed objects as defined by Figure 1 in [regrep-rim-v4.0]. The default
180 is to return all composed objects.

181 ● Attribute returnType - This optional attribute specifies the type of RegistryObject to return within
182 the response. Values for returnType are as follows:

183 ○ ObjectRef - This option specifies that the QueryResponse MUST contain a <rim:ObjectRe-
184 fList> element. The purpose of this option is to return references to objects rather than the ac-
185 tual objects.

186 ○ RegistryObject - This option specifies that the QueryResponse MUST contain a <rim:Re-
187 gistryObjectList> element containing <rim:RegistryObject> elements with xsi:type=“rim:Re-
188 gistryObjectType”.
regrep-core-rs-v4.0-os 25 January 2012
Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 19 of 95
189 ○ LeafClass - This option specifies that the QueryResponse MUST contain a collection of
190 <rim:RegistryObjectList> element containing <rim:RegistryObject> elements that have an
191 xsi:type attribute that corresponds to leaf classes as defined in [regrep-xsd-v4.0]. No Reposit-
192 oryItems SHOULD be included for any rim:ExtrinsicObjectType instance in the <rim:Registry-
193 ObjectList> element.

194 ○ LeafClassWithRepositoryItem - This option is the same as the LeafClass option with the addi-
195 tional requirement that the response include the RepositoryItems, if any, for every rim:Extrins-
196 icObjectType instance in the <rim:RegistryObjectList> element.

197 If “returnType” specified does not match a result returned by the query, then the server MUST use the
198 closest matching semantically valid returnType that matches the result. For example, consider a case
199 where a Query that matches rim:OrganizationType instances is asked to return LeafClassWithRepository-
200 Item. As this is not possible, QueryManager will assume the LeafClass option instead.

201 2.2.4 QueryResponse

202 The QueryResponse message is sent by the QueryManager in response to a QueryRequest when the
203 format requested by the client is the default ebrs format.

204 2.2.4.1 Syntax

<element name="QueryResponse">
<complexType>
<complexContent>
<extension base="rs:RegistryResponseType">
<attribute name="startIndex" type="integer" default="0"/>
<attribute name="totalResultCount" type="integer" use="optional"/>
</extension>
</complexContent>
</complexType>
</element>

205 2.2.4.2 Example

206 The following shows a sample response for the example QueryRequest presented earlier.
<query:QueryResponse totalResultCount="1" startIndex="0"
status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success">
<rim:RegistryObjectList>
<RegistryObject xsi:type="PersonType"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Submitted"
objectType="urn:oasis:names:tc:ebxml-
regrep:ObjectType:RegistryObject:Person"
lid="urn:acme:Person:Danyal" id="urn:acme:Person:Danyal">
<Name>
<LocalizedString value="Danyal Najmi" xml:lang="en-US"/>
</Name>
<VersionInfo versionName="1"/>
<PersonName lastName="Najmi" middleName="Idris" firstName="Danyal"/>
</RegistryObject>
</rim:RegistryObjectList>
</query:QueryResponse>

207 2.2.4.3 Description:

208 ● Element RegistryObjectList (inherited) - This is the element that contains the RegistryObject in-
209 stances that matched the specified query. A server MUST provide this element in a QueryRe-
210 sponse even if it contains no RegistryObject instances.

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 20 of 95
211 ● Attribute startIndex - This optional integer value is used to indicate the index for the first result in
212 the result set returned by the query, within the complete result set matching the query. By default,
213 this value is 0. This attribute is described further in the Iterative Queries section.

214 ● Attribute totalResultCount - This optional parameter specifies the size of the complete result set
215 matching the query within the server. When this value is unspecified, the client should assume it
216 is the size of the result set contained within the result. When this value is -1, the client should as-
217 sume that the number of total results is unknown. In this case the client should keep iterating
218 through the remaining result set for the query until no more results are returned. This attribute is
219 described further in the Iterative Queries section.

220 2.2.5 Iterative Queries

221 The QueryRequest and QueryResponse support the ability to iterate over a large result set matching a
222 query by allowing multiple QueryRequest requests to be submitted in succession such that each query re-
223 quests a different subset of results within the result set. This feature enables the server to handle queries
224 that match a very large result set, in a scalable manner. The iterative query feature is accessed via the
225 startIndex and maxResults parameters of the QueryRequest and the startIndex and totalResultCount
226 parameters of the QueryResponse as described earlier.

227 A server MUST return a result set whose size is less than or equal to the maxResults parameter depend-
228 ing upon whether enough results are available starting at startIndex.

229 The iterative queries feature is not a true Cursor capability as found in databases. A server is not required
230 to maintain transactional consistency or state between iterations of a query. Thus it is possible for new
231 objects to be added or existing objects to be removed from the complete result set in between iterations.
232 As a consequence it is possible to have a result set element be skipped or duplicated between iterations.
233 However, a server MUST return the same result in a deterministic manner for the same QueryRequest if
234 no changes have been made in between the request to the server (or servers in case of federated
235 queries).

236 Note that while it is not required, a server MAY implement a transactionally consistent iterative query fea-
237 ture.

238 2.3 Parameterized Query Definition

239 A parameterized query is defined by submitting a rim:QueryDefinitionType instance to the server using
240 the submitObjects protocol. A detailed specification of the rim:QueryDefinitionType is defined in ebRIM.
241 The definition of a parameterized query includes detailed specification of each supported parameter in-
242 cluding its name, description, data type, cardinality and domain.

243 2.4 Canonical Query: AdhocQuery

244 The canonical query AdhocQuery allows clients to invoke a client-specified ad hoc query in a client-spe-
245 cified query expression syntax that is supported by the server. This specification does not require a server
246 to support any specific query expression syntax. It is likely that servers may support one or more common
247 syntaxes such as SQL-92, XQuery, XPath, SPARQL, Search-WS, OGC Filter etc.

248 2.4.1 Parameter Summary

Parameter Description Data Type Default Value Cardinality

queryExpression string 1
Value is a query expression string in the
language specified by the queryLan-
guage parameter

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 21 of 95
 queryLanguage taxonomy- 1
Value is the id of a ClassificationNode
Element
within the canonical QueryLanguageS-
cheme ClassificationScheme.

249 2.4.2 Query Semantics

250 ● The queryExpression may specify any number of named parameters

251 ● The server MUST use rim:Slot child elements of the rim:Query as named parameters to the query
252 queryExpression

253 ● The server MUST return a QueryException fault message if the queryLanguage used by the
254 queryExpression is not supported by the server

255 ● The server SHOULD return an AuthorizationException fault message if the client is not authorized
256 to invoke this query

257 ● The server MUST return the objects matching the query if the query is processed without any ex-
258 ceptions

259 2.5 Canonical Query: BasicQuery

260 The canonical query BasicQuery allows clients to query for RegistryObjects by their name, description,
261 type, status and classifications.

262 2.5.1 Parameter Summary

Parameter Description Data Type Default Value Cardinality

classifications Set whose elements are path attribute val- string 0..*
ues to ClassificationNodes.
Matches RegistryObjects that have a classi-
fication whose classificationNode attribute
value matches the id of the Classification-
Node where
rim:RegistryObject[@xsi:type="rim:Classific-
ationNodeType"]/@path matches specified
value
When multiple values are specified it implies
a logical AND operation.

description Matches rim:RegistryObject/rim:Descrip- string 0..1

tion/rim:LocalizedString/@value

matchOnAnyParameter If true then use logical OR between predic- boolean false 0..1
ates for each parameter

name Matches string 0..1

rim:RegistryObject/rim:Name/rim:Localized-
String/@value

objectType Matches RegistryObjects whose objectType taxonomy- 0..1

attribute matches the id of the Classification- Element
Node where rim:ClassificationNode/@path
matches specified value

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 22 of 95
 owner Matches rim:RegistryObject/@owner. Note string 0..1
that a parameter value of “#@'@#rs:cur-
rentUserId()#@'@#” may be used to specify
the id of the user associated with the current
request

status Matches RegistryObjects whose status at- taxonomy- 0..1

tribute matches the id of the Classification- Element
Node where rim:ClassificationNode/@path
matches specified value

263 2.5.2 Query Semantics

264 ● This query has several optional parameters

265 ● Each parameter implies a predicate within the underlying query

266 ● Predicates for each supplied parameter are combined using with an implicit LOGICAL AND if
267 matchOnAnyParameter is unspecified or false. If it is specified as true then predicates for each
268 supplied parameters are combined using a LOGICAL OR

269 ● If an optional parameter is not supplied then its corresponding predicate MUST NOT be included
270 in the underlying query

271 2.6 Canonical Query: ClassificationSchemeSelector

272 The canonical query ClassificationSchemeSelector allows clients to create a Subscription to a remote
273 server to replicate a remote ClassificationScheme. This query may be used as Selector query in the sub-
274 scription as defined in the object replication feature.

275 2.6.1 Parameter Summary

Parameter Description Data Type Default Value Cardinality

classificationSchemeId string 1
Matches
rim:RegistryObject[@xsi:type="rim:Clas-
sificationSchemeType"]/@id.

Does not allow wildcards.

276 2.6.2 Query Semantics

277 ● The server MUST return the specified ClassificationScheme and all ClassificationNodes that are
278 descendants of that ClassificationScheme.

279 ● The ClassificationNodes MUST NOT be returned as nested elements inside their parent Tax-
280 onomy element. Instead they MUST be returned as sibling elements with the RegistryObjectList
281 element of the QueryResponse.

282 2.7 Canonical Query: FindAssociations

283 The canonical query FindAssociations query allows clients to find Associations that match the specified
284 criteria.

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 23 of 95
285 2.7.1 Parameter Summary
Parameter Description Data Type Default Value Cardinality

associationType Matches Associations whose type attribute taxonomy- 0..1

references a ClassificationNode where Element
rim:ClassificationNode/@path matches spe-
cified value

matchOnAnyParameter If true then use logical OR between predic- boolean false 0..1
ates for each parameter

sourceObjectId string 0..1

Matches
rim:/RegistryObject[@xsi:type="rim:As-
sociationType"]/@sourceObject.

Allows use of “%” wildcard character to

match multiple characters.

Allows use of “?” wildcard character to

match a single character.

sourceObjectType Matches Associations whose sourceObject taxonomy- 0..1

attribute references a RegistryObject whose Element
objectType attribute matches the id of the
ClassificationNode where rim:Classification-
Node/@path matches specified value

targetObjectId string 0..1

Matches
rim:/RegistryObject[@xsi:type="rim:As-
sociationType"]/@targetObject.

Allows use of “%” wildcard character to

match multiple characters.

Allows use of “?” wildcard character to

match a single character.

targetObjectType Matches Associations whose targetObject taxonomy- 0..1

attribute references a RegistryObject whose Element
objectType attribute matches the id of the
ClassificationNode where rim:Classification-
Node/@path matches specified value

286 2.7.2 Query Semantics

287 ● All parameters are optional

288 ● The server MUST return the objects matching the query if the query is processed without any ex-
289 ceptions

290 ● Predicates for each supplied parameter are combined using an implicit LOGICAL AND if
291 matchOnAnyParameter is unspecified or false. If it is specified as true then predicates for each
292 supplied parameters are combined using a LOGICAL OR

293 2.8 Canonical Query: FindAssociatedObjects

294 The canonical query FindAssociatedObjects allows clients to find RegistryObjects that are associated with
295 the specified RegistryObject and match the specified criteria.
regrep-core-rs-v4.0-os 25 January 2012
Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 24 of 95
296 2.8.1 Parameter Summary
Parameter Description Data Type Default Value Cardinality

associationType taxonomy- 0..1

Matches associated RegistryObjects of
Element
Association's whose type attribute refer-
ences a ClassificationNode where
rim:ClassificationNode/@path matches
specified value

matchOnAnyParameter If true then use logical OR between predic- boolean false 0..1
ates for each parameter

sourceObjectId string 0..1

Matches target RegistryObjects of As-
sociations where the source Registry-
Object's id matches rim:/RegistryOb-
ject[@xsi:type="rim:AssociationType"]/
@sourceObject.

Allows use of “%” wildcard character to

match multiple characters.

Allows use of “?” wildcard character to

match a single character.

sourceObjectType Matches target RegistryObjects of Associ- taxonomy- 0..1

ations whose sourceObject attribute refer- Element
ences a RegistryObject whose objectType
attribute matches the id of the Classification-
Node where rim:ClassificationNode/@path
matches specified value

targetObjectId string 0..1

Matches source RegistryObjects of As-
sociations where the target RegistryOb-
ject's id matches
rim:/RegistryObject[@xsi:type="rim:As-
sociationType"]/@targetObject.

Allows use of “%” wildcard character to

match multiple characters.

Allows use of “?” wildcard character to

match a single character.

targetObjectType Matches source RegistryObjects of Associ- taxonomy- 0..1

ations whose targetObject attribute refer- Element
ences a RegistryObject whose objectType
attribute matches the id of the Classification-
Node where rim:ClassificationNode/@path
matches specified value

297 2.8.2 Query Semantics

298 ● All parameters are optional

299 ● The server MUST return the objects matching the query if the query is processed without any ex-
300 ceptions

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 25 of 95
301 ● Either sourceObjectId or targetObjectId MUST be specified. If neither are specified then QueryEx-
302 ception fault MUST be returned

303 ● Both sourceObjectId and targetObjectId MUST NOT be specified. If both are specified then
304 QueryException fault MUST be returned

305 ● Predicates for each supplied parameter are combined using an implicit LOGICAL AND if
306 matchOnAnyParameter is unspecified or false. If it is specified as true then predicates for each
307 supplied parameters are combined using a LOGICAL OR

308 2.9 Canonical Query: GarbageCollector

309 The canonical query GarbageCollector allows clients to find RegistryObjects that are deemed as garbage
310 by the server.

311 2.9.1 Parameter Summary

312 This query specifies no parameters.

313 2.9.2 Query Semantics

314 ● The server MAY return any objects it considers as garbage or no longer relevant or needed

315 ● The definition of what objects are garbage may be implementation, profile or deployment specific

316 ● The server MUST return the following types of objects

317 ○ Dangling Associations - AssociationType instances that have an unresolvable or null

318 sourceObject or targetObject attribute

319 2.10 Canonical Query: GetAuditTrailById

320 The canonical query GetAuditTrailById allows clients to get the change history or audit trail for a Re-
321 gistryObject whose id attribute value is the same as the value of the id parameter.

322 2.10.1 Parameter Summary

Parameter Description Data Type Default Value Cardinality

endTime dateTime 0..1

Specifies the end of the time interval (in-
clusive) for
rim:/RegistryObject[@xsi:type="rim:Audit
ableEventType"]/@timestamp value

id string 1
Matches rim:/RegistryObject/@id.

startTime dateTime 0..1

Specifies the end of the time interval (in-
clusive) for
rim:/RegistryObject[@xsi:type="rim:Audit
ableEventType"]/@timestamp value

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 26 of 95
323 2.10.2 Query Semantics
324 ● The server MUST return a set of AuditableEvents that affected the object with id matching the
325 specified id parameter value. The set is sorted by the timestamp attribute value in descending or-
326 der (latest first)

327 ● If startTime is specified the server MUST only include AuditableEvents whose timestamp is >=
328 startTime parameter value

329 ● If endTime is specified the server MUST only include AuditableEvents whose timestamp is <= en-
330 dTime parameter value

331 2.11 Canonical Query: GetAuditTrailByLid

332 The canonical query GetAuditTrailByLid allows clients to get the change history or audit trail for all Re-
333 gistryObjects whose lid attribute value is the same as the value of the lid parameter.

334 2.11.1 Parameter Summary

Parameter Description Data Type Default Value Cardinality

endTime dateTime 0..1

Specifies the end of the time interval (in-
clusive) for
rim:/RegistryObject[@xsi:type="rim:Audit
ableEventType"]/@timestamp value

lid string 1
Matches rim:/RegistryObject/@lid.

startTime dateTime 0..1

Specifies the end of the time interval (in-
clusive) for
rim:/RegistryObject[@xsi:type="rim:Audit
ableEventType"]/@timestamp value

335 2.11.2 Query Semantics

336 ● The server MUST return a set of AuditableEvents that affected objects with lid matching the spe-
337 cified lid parameter value. The set is sorted by the timestamp attribute value in descending order
338 (latest first)

339 ● If startTime is specified the server MUST only include AuditableEvents whose timestamp is >=
340 startTime parameter value

341 ● If endTime is specified the server MUST only include AuditableEvents whose timestamp is <= en-
342 dTime parameter value

343 2.12 Canonical Query: GetAuditTrailByTimeInterval

344 The canonical query GetAuditTrailByTimeInterval allows clients to get all changes to all objects in the
345 server within a specified time interval. This query may be used to keep a client periodically synchronized
346 with changes in the server.

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 27 of 95
347 2.12.1 Parameter Summary
Parameter Description Data Type Default Value Cardinality

endTime dateTime 5 minutes be- 0..1

Specifies the end of the time interval (in-
fore current
clusive) for time
rim:/RegistryObject[@xsi:type="rim:Audit
ableEventType"]/@timestamp value

startTime dateTime Current time 0..1

Specifies the end of the time interval (in-
clusive) for
rim:/RegistryObject[@xsi:type="rim:Audit
ableEventType"]/@timestamp value

348 2.12.2 Query Semantics

349 ● The server MUST return a set of AuditableEvents whose timestamp attribute is within the time in-
350 terval specified by startTime and endTime parameters. The set is sorted by the timestamp attrib-
351 ute value in descending order (latest first)

352 ● The server MUST only include AuditableEvents whose timestamp is >= startTime parameter
353 value

354 ● The server MUST only include AuditableEvents whose timestamp is <= endTime parameter value

355 2.13 Canonical Query: GetChildrenByParentId

356 The canonical query GetChildrenByParentId allows clients to get the children of a RegistryObject whose
357 Id attribute value is the same as the value specified for the parentId parameter. This query is used to
358 query objects hierarchies with parent-child relationships such as the following:

359 ● ClassificationScheme – Child ClassificationNodes

360 ● Organization – Child Organizations

361 ● RegistryPackage – RegistryPackage Members

362 2.13.1 Parameter Summary

Parameter Description Data Type Default Value Cardinality

depth Specifies how many levels of descendants to integer 1 0..1

fetch:
•depth > 0 implies get descendants upto
“depth” levels
•depth <= 0 implies get all descendants

exclusiveChildrenOnly Specifies how to handle children that may boolean false 0..1
have multiple parents:
• True value specifies that only chil-
dren that are not children of any
other parent should be returned
• false value specifies that children

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 28 of 95
 that have other parents should also
be matched

objectType Specifies the type of object hierarchy for the string 0..1
query

parentId string 0..1

Specifies the id of the parent object

363 2.13.2 Query Semantics

364 ● If objectType and parentId are both unspecified the server MUST return all RegistryObjects that
365 are not members of a RegistryPackage (root level objects)

366 ● If parentId parameter is unspecified and objectType parameter is specified the server MUST re-
367 turn all root level objects for the object hierarchy identified by the objectType as follows:

368 ○ If objectType parameter value contains the string “ClassificationScheme” the server MUST
369 return all ClassificationSchemes

370 ○ If objectType parameter value contains the string “Organization” the server MUST return all
371 Organizations that are not a member of another Organization (root level Organizations)

372 ○ If objectType parameter value contains the string “RegistryPackage” the server MUST return
373 all RegistryPackages that are not a member of another RegistryPackage (root level Re-
374 gistryPackages)

375 ● If parentId parameter is specified then the behavior is as follows:

376 ○ If objectType parameter value is unspecified or if its value contains the string “RegistryPack-
377 age” the server MUST return all RegistryObjects that are member of a RegistryPackage
378 whose id is the same as the value of the parentId attribute

379 ○ If objectType parameter is specified and its value contains the string “ClassificationScheme”
380 the server MUST return all ClassificationNodes that are children of a TaxonomyElementType
381 instance whose id is the same as the value of the parentId attribute

382 ○ If objectType parameter is specified and its value contains the string “Organization” the server
383 MUST return all Organizations that are members of an Organization whose id is the same as
384 the value of the parentId attribute

385 ● If depth parameter is specified then the server MUST also return all descendants upto the spe-
386 cified depth as described by the definition of the depth parameter above

387 ● If exclusiveChildrenOnly is specified with a true value then the server MUST not return any des-
388 cendants that have multiple parents

389 2.14 Canonical Query: GetClassificationSchemesById

390 The canonical query GetClassificationSchemesById allows clients to fetch specified ClassificationS-
391 chemes.

392 2.14.1 Parameter Summary

Parameter Description Data Type Default Value Cardinality
regrep-core-rs-v4.0-os 25 January 2012
Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 29 of 95
 id string 0..1
Matches
rim:/RegistryObject[@xsi:type="rim:Clas
sificationSchemeType"]/@id.

Allows use of “%” wildcard character to

match multiple characters.

Allows use of “?” wildcard character to

match a single character.

393 2.14.2 Query Semantics

394 ● The server MUST return the objects matching the query if the query is processed without any ex-
395 ceptions

396 ● The depth parameter of the QueryRequest may be used to pre-fetch the ClassificationNodes of
397 matches ClassificationSchemes

398 2.15 Canonical Query: GetRegistryPackagesByMemberId

399 The canonical query GetRegistryPackagesByMemberId allows clients to get the RegistryPackages that a
400 specified RegistryObject is a member of.

401 2.15.1 Parameter Summary

Parameter Description Data Type Default Value Cardinality

memberId string 0..1

Matches RegistryPackages that have a
RegistryObject as an immediate member
where the RegistryObject's id rim:Re-
gistryObject/@id matches the specified
value.

Allows use of “%” wildcard character to

match multiple characters.

Allows use of “?” wildcard character to

match a single character.

402 2.15.2 Query Semantics

403 ● The server MUST return the objects matching the query if the query is processed without any ex-
404 ceptions

405 2.16 Canonical Query: GetNotification

406 The canonical query GetNotification allows clients to “pull” any pending Notification for a Subscription at a
407 time of their choosing. This is defined in detail under section titled “Pulling Notification on Demand”.

408 2.16.1 Parameter Summary

Parameter Description Data Type Default Value Cardinality
regrep-core-rs-v4.0-os 25 January 2012
Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 30 of 95
 subscriptionId string 1
Matches
rim:/RegistryObject[@xsi:type="rim:Sub-
scriptionType"]/@id.

Wildcards are not allowed.

startTime xs:dateTime 0..1

The time since which events should be
included in the Notification

409 2.16.2 Query Semantics

410 ● The server MUST return a Notification with events that affected objects matching the query se-
411 lector query for the Subscription.

412 ● The server MUST return only those events that have a timestamp later than startTime.

413 2.17 Canonical Query: GetObjectById

414 The canonical query GetObjectById allows clients to find RegistryObjects based upon the value of their id
415 attribute.

416 2.17.1 Parameter Summary

Parameter Description Data Type Default Value Cardinality

id string 1
Matches rim:RegistryObject/@id.

Allows use of “%” wildcard character to

match multiple characters.

Allows use of “?” wildcard character to

match a single character.

417 2.17.2 Query Semantics

418 ● The server MUST return the RegistryObjects whose id attribute value matches the specified value
419 of the id parameter.

420 2.18 Canonical Query: GetObjectsByLid

421 The canonical query GetObjectByLid allows clients to find RegistryObjects based upon the value of their
422 lid attribute. It is used to fetch all versions of a logical object without any specific order or relationship
423 among them.

424 2.18.1 Parameter Summary

Parameter Description Data Type Default Value Cardinality

lid string 1
Matches rim:RegistryObject/@lid.

Allows use of “%” wildcard character to

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 31 of 95
 match multiple characters.

Allows use of “?” wildcard character to

match a single character.

425 2.18.2 Query Semantics

426 ● The server MUST return all RegistryObjects whose lid attribute value matches the specified value
427 of the lid parameter.

428 2.19 Canonical Query: GetReferencedObject

429 The canonical query GetReferencedObject allows clients to get a RegistryObject that is the target of an
430 rim:objectReferenceType attribute value.

431 2.19.1 Parameter Summary

Parameter Description Data Type Default Value Cardinality

objectReference string 0..1

Contains the value for a rim:objectRefer-
enceType attribute

432 2.19.2 Query Semantics

433 ● The server MUST return the RegistryObjectType instance that is being referenced by the spe-
434 cified value for the objectReference parameter.

435 ○ If the objectReference contains the id of a local object that is not a DynamicObjectRef in-
436 stance then the server MUST return that object.

437 ○ If the objectReference contains the id of a local DynamicObjectRef instance then the server
438 MUST invoke the Query within the DynamicObjectRef instance and resolve the reference to
439 the singleton result of the Query and return the matching object.

440 ○ If the objectReference contains the canonical URL for a remote object then the server MUST
441 invoke the GetReferencedObject query against the remote server using the id of the remote
442 object as the value of the objectReference parameter and return the matching object. The id
443 of the remote object is accessible from its canonical URL as the value of the id parameter
444 within the URL.

445 2.20 Canonical Query: KeywordSearch

446 The canonical query KeyWordSearch allows clients to find RegistryObjects and RepositoryItems that con-
447 tain text that matches keywords identified by specified search patterns.

448 2.20.1 Canonical Indexes

449 This query defines a set of canonical index names as defined by table below. Each index name is associ-
450 ated with a particular type of information that it indexes. A server MUST index all information that is
451 defined by the canonical indexes below. A server MAY define additional indexes to index information not
452 specified by this section.

453

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 32 of 95
 Index Name Description

name.localizedString.value Indexes the value of all localized string in all Name ele-
ments of all RegistryObjects

description.localizedString.value Indexes the value of all localized string in all Description

elements of all RegistryObjects

slot.name Indexes the name of all slots on all RegistryObjects

slot.value Indexes the value of all slots on all RegistryObjects

repositoryItem Indexes the text of all text based repository items associ-
ated with ExtrinsicObjects

personName.firstName Indexes the firstName attribute of PersonName elements

in all Person objects

personName.middleName Indexes the middleName attribute of PersonName ele-

ments in all Person objects

personName.lastName Indexes the lastName attribute of PersonName elements

in all Person objects

emailAddress.address Indexes the address attribute of all EmailAddress objects

postalAddress.city Indexes the city attribute of all PostalAddress elements

contained within any RegistryObject

postalAddress.country Indexes the country attribute of all PostalAddress ele-

ments contained within any RegistryObject

postalAddress.postalCode Indexes the postalCode attribute of all PostalAddress

elements contained within any RegistryObject

postalAddress.stateOrProvince Indexes the stateOrProvince attribute of all PostalAd-

dress elements contained within any RegistryObject

postalAddress.street Indexes the street attribute of all PostalAddress elements

contained within any RegistryObject

454

455

456 2.20.2 Parameter Summary

Parameter Description Data Type Default Value Cardinality

keywords string 1
A space separated list of keywords to
search for

457 2.20.3 Query Semantics

458 The value of the keywords parameter may consist of multiple terms where each term is separated
459 by one or more spaces
460
461 Example: ebxml regrep

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 33 of 95
462 Semantics: Matches objects containing either “ebxml” or “regrep”

464 ● A term may be enclosed in double-quotes to include white space characters as a literal value.
465
466 Example: “ebxml regrep”
467 Semantics: Matches objects containing “ebxml regrep”

469 ● Terms may be specified using wildcard characters where '*' matches one or more characters and
470 “?” matches a single character.
471
472 Example: eb?ml reg*

474 ● Terms may be combined using boolean operators “AND”, “OR” and “NOT”. Absence of a boolean
475 operator between terms implies an implicit OR operator between them.

476 ●
477 Example: ebxml AND regrep
478 Semantics: Matches objects containing “ebxml” and “regrep”
479
480 Example: ebxml NOT regrep
481 Semantics: Matches objects containing “ebxml” and not containg “regrep”
482
483 Example: ebxml OR regrep
484 Semantics: Matches objects containing “ebxml” or “regrep”
485
486 Example: ebxml regrep
487 Semantics: Matches objects containing “ebxml” or “regrep”

489 ● Terms may be grouped together using “(“ at the beginning and “)” at the end of the group. Group-
490 ing allowing boolean operators to be applied to a group of terms as a whole and enables more
491 flexible searches.
492
493 Example: ebxml AND (registry OR regrep)
494 Semantics: Matches objects containing both “ebxml” and either “registry” or “regrep”

495 ● The server MUST return all RegistryObjects that contain indexed data matching the semantics of
496 the keywords parameter.

497 ● The server MUST return all ExtrinsicObjects that have a repository item that contains indexed
498 data matching the semantics of the keywords parameter.

499 2.21 Canonical Query: RegistryPackageSelector

500 The canonical query RegistryPackageSelector allows clients to create a Subscription to a remote server
501 to replicate a remote RegistryPackage as well as all its member objects and the AssociationType in-
502 stances that relate the members of the RegistryPackage to it. This query MAY be used as Selector query
503 within the Subscription for the replication as defined in the object replication feature.

504 2.21.1 Parameter Summary

Parameter Description Data Type Default Value Cardinality

registryPackageIds string 1..*

A set of IDs of rim:RegistryPackageType

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 34 of 95
 instances. Does not allow wildcards.

505 2.21.2 Query Semantics

506 ● The server MUST return the specified RegistryPackageType instance, all RegistryObjectType in-
507 stances that are members of the specified RegistryPackage as well as all “HasMember” Associ-
508 ationType instances between the RegistryPackageType instance and its members, that are des-
509 cendants of that ClassificationScheme.

510 ● The member RegistryObjectType instances MUST NOT be returned as nested elements inside
511 the RegistryPackage. Instead they MUST be returned as sibling elements with the RegistryPack-
512 age and Associations within the RegistryObjectList element of the QueryResponse.

513 2.22 Query Functions

514 A server MAY support any number of functions known as Query Functions, that may be used within a
515 query expression or query parameter. Query functions are similar in concept to functions in SQL. Query
516 functions may be used within the query expression of a parameterized query as well as within its invoca-
517 tion parameter values. Query functions enable parameterized queries to use specialized search al-
518 gorithms to augment their capabilities.

519 This specification defines a number of canonical functions that are standard functions that MUST be sup-
520 ported by a server. Profiles, implementations and deployments may define additional query functions bey-
521 ond the canonical functions defined by this specification.

522 2.22.1 Using Functions in Query Expressions

523 A parameterized query stored as a rim:QueryDefinition instance MAY have a rim:QueryExpression which
524 defines a query expression within its sub-nodes. A client MAY submit a rim:QueryDefinition such that its
525 query expression may use any number of query functions supported by the server any where within the
526 query expression where it is syntactically correct to use the value returned by the function.

527 If a query expression contains one or more function invocations then the query expression MUST delimit
528 the parts of the query expression that are not a function invocation with the leading characters “#@” and
529 trailing characters “@#”. This is similar in syntax to a Java multi-line comment syntax where a comment is
530 delimited by leading characters “/*” and trailing characters “*/”. The delimiters serve the following pur-
531 poses:

532 ● Allows a parser to recognize the non-function parts of the query expression that MUST be pre-
533 served as is

534 ● Allows implementations to be optimized to skip function parsing and evaluation if the special de-
535 limiter characters are not present in query expression

536 The following is an example of a SQL query expression which uses the getClassificationNodes function to
537 match all RegistryObjects that are targets of Association with specified sourceObject and type that is a
538 subnode of AffiliatedWith node upto a depth of 2 levels in the descendant hierarchy. The delimiter charac-
539 ters are in bold font while the function invocations is in bold and italic font below:
--example of a query expression with query functions
#@SELECT targetObject.* FROM
RegistryObjectType targetObject, AssociationType a WHERE

a.sourceObject = :sourceObject AND

a.type IN (@# getClassificationNodes("urn:oasis:names:tc:ebxml-
regrep:AssociationType:AffiliatedWith", 0, 2, "false", ",", "${id}") #@) AND
targetObject.id = a.targetObject@#

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 35 of 95
540 2.22.2 Using Functions in Query Parameters
541 A client MAY use query functions supported by a server within parameter values specified when invoking
542 a parameterized query. A client MAY invoke a parameterized query using the Query protocol such that its
543 query parameter values may use any number of query functions supported by the server any where within
544 the query parameter where it is syntactically correct to use the value returned by the function.

545 If a query parameter value contains one or more function invocations then the query expression MUST
546 delimit the parts of the query parameter that are not a function invocation with the leading characters
547 “#@” and trailing characters “@#”. If a query parameter value only has function invocations and contains
548 no non-function parts then it must include at least one leading or trailing “#@@#” delimiter token pair to
549 allow optimized parsing and evaluation of query functions only when needed.

550 The following is an example of a query expression that has no query functions. Its two parameters are
551 shown in bold font:
--Following is the query expression within the server
--This time it has no query functions as they are in the query parameters
SELECT targetObject.* FROM
RegistryObjectType targetObject, AssociationType a WHERE

a.sourceObject = :sourceObject AND

a.type IN ( :types ) AND
targetObject.id = a.targetObject

552

553 The following is an example of invocation of a parameterized query that uses the above query expression
554 and uses the getClassificationNodes function from previous example within the value of the types para-
555 meter. Note the trailing “#@@#” delimiter tokens are present as required.

556
<query:QueryRequest maxResults="-1" startIndex="0" ...>
<rs:ResponseOption returnComposedObjects="true"
returnType="LeafClassWithRepositoryItem"/>
<query:Query queryDefinition="urn:acme:ExampleQuery">
<rim:Slot name="sourceObject">
<rim:SlotValue xsi:type="StringValueType"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<rim:Value>urn:test:Person:Danyal</rim:Value>
</rim:SlotValue>
<rim:Slot name="types">
<rim:SlotValue xsi:type="StringValueType"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<rim:Value>getClassificationNodes("urn:oasis:names:tc:ebxml-
regrep:AssociationType:AffiliatedWith", 0, 2, "false", ",", "$
{id}")#@@#</rim:Value>
</rim:SlotValue>
</rim:Slot>
</query:Query>
</query:QueryRequest>

557 2.22.3 Function Processing Model

558 A server MUST meet the following function processing requirements during the processing of a QueryRe-
559 quest:

560 ● When processing a query expression elements (rim:QueryDefinition/rim:QueryExpression) the

561 server SHOULD NOT perform function processing if the special delimiter sequences of “#@” and
562 “@#” are not found in the query expression

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 36 of 95
563 ● When processing query invocation parameter elements
564 (query:QueryRequest/query:Query/rim:Slot/rim:SlotValue) the server SHOULD NOT perform
565 function processing if the special delimiter sequences of “#@” and “@#” are not found in the
566 query expression

567 ● When processing a query expression element if the special delimiter sequences of “#@” and
568 “@#” are found then the server MUST process query expression elements to replace all function
569 invocations with the value returned when the function is invoked with specified parameters

570 ● When processing query invocation parameter elements if the special delimiter sequences of “#@”
571 and “@#” are found then the server MUST process each query parameter element to replace all
572 function invocations with the value returned when the function is invoked with specified paramet-
573 ers

574 ● When invoking a function that has another function invocation as its parameter the inner most
575 functions MUST be invoked first so that the outer function can be invoked with the value returned
576 by the inner function invocation

577 ● When processing a query expression or query parameter the special delimiter characters “#@”
578 and “@#” MUST be removed and the value contained within them MUST be preserved without
579 any change

580 2.22.4 Function Processor BNF

581 The following BNF grammar normatively describes the grammar for query expressions and query invoca-
582 tion parameters with embedded function invocations. The start production describes the grammar for
583 query expressions and query invocation parameters with embedded function invocations.

584
<DEFAULT> SKIP : {
" "
| "\t"
| "\r"
| "\n"
}

<DEFAULT> TOKEN : {
<FLOAT: <INTEGER> "." <INTEGER> | "." <INTEGER> | <INTEGER> ".">
| <INTEGER: (<DIGIT>)+>
| <DIGIT: ["0"-"9"]>
| <BOOLEAN: "true" | "false">
}

<DEFAULT> TOKEN : {
<S_IDENTIFIER: (<LETTER>)+ (<DIGIT> | <LETTER> | <SPECIAL_CHARS>)*>
| <#LETTER: ["a"-"z","A"-"Z"]>
| <#SPECIAL_CHARS: "_">
| <S_CHAR_LITERAL: "\'" (~["\'"])* "\'" ("\'" (~["\'"])* "\'")*>
| <S_QUOTED_IDENTIFIER: "\"" (~["\n","\r","\""])* "\"">
| <OPENPAREN: "(">
| <CLOSEPAREN: ")">
| <COMMA: ",">
| <COLON: ":">
| <DELIMITED_TEXT: "#@" (~["@"])* "@#">
}

start ::= ( textOrFunctionCall )+ <EOF>

regrep-core-rs-v4.0-os 25 January 2012
Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 37 of 95
 text ::= ( ( <DELIMITED_TEXT> ) )
textOrFunctionCall ::= ( text | FunctionCall )
FunctionCall ::= FunctionReference <OPENPAREN> ( FunctionArgumentList )*
<CLOSEPAREN>
FunctionReference ::= <S_IDENTIFIER> <COLON> <S_IDENTIFIER>
FunctionArgumentList ::= FunctionArgument ( <COMMA> FunctionArgument )
*
FunctionArgument ::= ( FunctionCall | <S_CHAR_LITERAL> |
<S_QUOTED_IDENTIFIER> | <FLOAT> | <INTEGER> | <BOOLEAN> )

585 2.23 Common Patterns In Query Functions

586 This section defines some commonly occurring patterns in query functions and defines some common
587 solutions to addressing these patterns. Profiles SHOULD conform to the solutions defined in this section
588 whenever possible.

589 2.23.1 Specifying a null Value for string Param or Return Value
590 A function that accepts a string parameter SHOULD treat a value of “rs:null” as a null string. A null string
591 is a string whose value is unspecified.

592 When a function returns a “string” type it SHOULD return a null value string as the canonical value
593 “rs:null”.

594 2.24 Canonical Functions

595 This section defines a set of standard canonical functions that MUST be supported by all servers. A client
596 MAY use these functions within a query expression or within the value of a parameter to a parameterized
597 query. A server MUST process the functions according to their behavior as specified in this section. The
598 function processing model is specified in Function Processing Model.

599 A client MUST use the “rs:” namespace prefix when using a canonical function defined by this profile. Pro-
600 files of this specification MAY define their own canonical functions as well as a standard namespace pre-
601 fix to be used with these functions.

602 A client MUST specify the parameters of a function in the same order as specified in the table for the
603 function specification.

604 Table 1 summarizes the canonical functions defined by this specification.

605
Function Name Semantics

currentTime Returns the current time in ISO 8601 format

currentUserId Returns the id of the user associated with the current RegistryRequest

relativeTime Returns a time in the future or past, relative to the current time where
the offset period is determined by specified parameter

getClassificationNodes Returns all ClassificationNode's that are descendants and / or ancestor

of the specified reference ClassificationNode and within the specified
number of levels as indicated by the ancestorLevels and descendant-
Levels parameters.

Table 1: Canonical Functions Defined By This Profile

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 38 of 95
606 2.24.1 Canonical Function: currentTime
607 This canonical function takes no parameters and returns the current time associated with the server.

608 2.24.1.1 Function Semantics

609 ● The server MUST return a string if the query is processed without any exceptions

610 ● The value of the string MUST be current time in ISO 8601 format using the UTC time zone. An
611 example of value returned is “2010-02-25T15:22:14.534Z”.

612 2.24.2 Canonical Function: currentUserId

613 This canonical function takes no parameters and returns a string whose value is the id of the user associ-
614 ated with the current RegistryRequest. This specification does not define how user's are managed within
615 the server nor does it define how an id is assigned to a user.

616 2.24.2.1 Function Semantics

617 ● The server MUST return a string if the query is processed without any exceptions

618 ● The value of the string MUST be “rs:null” if no current user is associated with the RegistryRe-
619 quest

620 2.24.3 Canonical Function: relativeTime

621 This canonical function takes a string parameter in the format specified by xs:duration that specify a time
622 offset period and returns a time in the future or past relative to the current time by the specified period.

623 2.24.3.1 Parameter Summary

Parameter Description Data Type

duration duration
A duration of time in the format as specified by the duration type
defined by XML Schema duration type. The duration format supports
negative or positive durations so this function may be used to return a
time relative to current in the future or the past.

624 2.24.3.2 Function Semantics

625 ● The server MUST return a string if the query is processed without any exceptions

626 ● The format of the duration parameter MUST conform to the format as specified by the duration
627 type defined by XML Schema duration type otherwise the server MUST return InvalidRequestEx-
628 ception

629 ● The value of the string MUST be a time in ISO 8601 format that is offset by the specified period in
630 the future relative to the current time. An example of value returned is “2010-02-
631 25T15:22:14.534Z”

632 2.24.4 Canonical Function: getClassificationNodes

633 This canonical function takes a reference ClassificationNode's id as parameter and returns all Classifica-
634 tionNode's that are descendants and/or ancestors of the specified reference ClassificationNode and
regrep-core-rs-v4.0-os 25 January 2012
Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 39 of 95
635 within the specified number of levels as indicated by the ancestorLevels and descendantLevels paramet-
636 ers.

637 2.24.4.1 Parameter Summary

Parameter Description Data Type

nodeId string
Specifies the id of the reference ClassificationNodeType instance

ancestorLevels integer
Specifies how many levels to match ancestors of reference node

descendantLevels integer
Specifies how many levels to match descendants of reference node

includeSelf boolean
Specifies whether to include the reference ClassificationNodeType in-
stance or not

delimiter string
The value of this parameter specifies the delimiter string to be used as
separator between the tokens representing the ids matched by the
function

template string
The value of this parameter specifies a template to contain each id re-
turned by the function. The template may contain one or more occur-
rences of template parameter string “${id}” as placeholder for the id of a
matched ClassificationNode

638 2.24.4.2 Function Semantics

639 ● The server MUST return a string if the query is processed without any exceptions

640 ● The string MUST be “rs:null” if no ClassificationNode is found that matches the function paramet-
641 ers

642 ● The string MUST consist of a set of substrings separated by the appropriate delimiter character
643 when any ClassificationNode's are found that match the function parameters:

644 ○ There MUST be a substring for each ClassificationNode matched by the function

645 ○ Each substring MUST conform to the specified template such that all occurrences of ${id} are
646 replaced by the id of a ClassificationNode matched by the function

647 ● The id of the reference ClassificationNode MUST be included if and only if the includeSelf para-
648 meter value is true

649 ● A ancestorLevels value of N where N > 0 matches all ClassificationNodes upto the Nth level an-
650 cestors of the reference ClassificationNode. A value of 1 matches the immediate parents of the
651 reference ClassificationNode while a value of 2 matches the parents and grandparents of the ref-
652 erence ClassificationNode. A value of -1 matches all ancestors of the reference Classification-
653 Node

654 ● A descendantsLevels value of N where N > 0 matches all ClassificationNodes upto the Nth level
655 descendants of the reference ClassificationNode. A value of 1 matches the immediate children of
656 the reference ClassificationNode while a value of 2 matches the children and grandchildren of
657 the reference ClassificationNode. A value of -1 matches all descendants of the reference Classi-
658 ficationNode

659 ● A template value of “rs:null” is implicitly equivalent to a template value of “${id}”

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 40 of 95
660

661 2.25 Query Plugins

662 Query plugins allow a server to use specialized extension modules to implement support for a parameter-
663 ized query. Since query plugins are software modules, they are able to handle highly specialized query
664 semantics that may not be expressed in most query languages. A specific instance of a query plugin is
665 designed and configured to handle a specific parameterized query.

666 2.25.1 Query Plugin Interface

667 A Query plugin implements the QueryManager interface. A QueryManager endpoint MUST delegate an
668 executeQuery operation to a Query plugin if a Query plugin has been configured for the requested para-
669 meterized query. A Query plugin MUST process the query and return a QueryResponse or fault message
670 to the QueryManager. The QueryManager MUST then deliver that response to the client.

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 41 of 95
671 3 LifecycleManager Interface
672 The LifecycleManager interface allows a client to perform various lifecycle management operations on
673 RegistryObjects. These operations include submitting RegistryObjects to the server, updating Registry-
674 Objects in the server, creating new versions of RegistryObjects in the server and removing RegistryOb-
675 jects from the server.

676 A server MUST implement the LifecycleManager interface as an endpoint.

677 3.1 SubmitObjects Protocol

678 The SubmitObjects protocol allows a client to submit RegistryObjects to the server. It also allows a client
679 to completely replace existing RegistryObjects in the server.

680 A client initiates the SubmitObjects protocol by sending a SubmitObjectsRequest message to the Life-
681 cycleManager endpoint.

682 The LifecycleManager sends a RegistryResponse back to the client as response.

683

Illustration 2: SubmitObjects Protocol

685 3.1.1 SubmitObjectsRequest

686 The SubmitObjectsRequest message is sent by a client to submit RegistryObjects to the server.

687 3.1.1.1 Syntax

<simpleType name="mode">
<restriction base="NCName">
<enumeration value="CreateOrReplace"/>
<enumeration value="CreateOrVersion"/>
<enumeration value="CreateOnly"/>
</restriction>
</simpleType>

<element name="SubmitObjectsRequest">
<complexType>
<complexContent>
<extension base="rs:RegistryRequestType">
<sequence>
<element ref="rim:RegistryObjectList" minOccurs="0" maxOccurs="1"/>
</sequence>

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 42 of 95
 <attribute name="checkReferences" type="boolean" use="optional"
default="false"/>
<attribute name="mode" type="tns:mode" use="optional"
default="CreateOrReplace"/>
</extension>
</complexContent>
</complexType>
</element>

688 3.1.1.2 Description

689 ● Element RegistryObjectList - Specifies a set of RegistryObject instances that are being submitted
690 to the server. The RegistryObjects in the list may be new objects being submitted to the server or
691 they may be current objects already existing in the server.

692 ● Attribute checkReferences – Specifies the reference checking behavior expected of the server

693 ○ true - Specifies that a server MUST check submitted objects and make sure that all refer-
694 ences via reference attributes and slots to other RegistryObjects are resolvable. If a reference
695 does not resolve then the server MUST return UnresolvedReferenceException

696 ○ false (default) – Specifies that a server MUST NOT check submitted objects to make sure
697 that all references via reference attributes and slots to other RegistryObjects are resolvable. If
698 a reference does not resolve then the server MUST NOT return UnresolvedReferenceExcep-
699 tion

700 ● Attribute mode – Specifies the semantics for how the server should handle RegistryObjects being
701 submitted when they already exist in the server:

702 ○ CreateOrReplace (default) - If an object does not exist, server MUST create it as a new ob-
703 ject. If an object already exists, server MUST replace the existing object with the submitted
704 object

705 ○ CreateOrVersion - If an object does not exist, server MUST create it as a new object. If an
706 object already exists, server MUST not alter the existing object and instead it MUST create a
707 new version of the existing object using the state of the submitted object

708 ○ CreateOnly - If an object does not exist, server MUST create it as a new object. If an object
709 already exists, the server MUST return an ObjectExistsException fault message

710 3.1.1.3 id and lid Requirements

711 Table 2 defines the requirements for id and lid attribute values for RegistryObjectType instances that are
712 submitted via the SubmitObjects protocol.

713

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 43 of 95
 Mode / Require- ID Requirements LID Requirements
ments

CreateOrReplace ● MUST be specified by client or else ● MUST be specified by client or else

server MUST return InvalidReques- server MUST return InvalidRequestEx-
tException ception
● If id does not exists, server MUST
create new object using that id (cre-
ate)
● If id exists, server MUST replace ex-
isting object matching that id (up-
date)

CreateOrVersion ● MUST be specified by client or else ● MUST be specified by client or else

server MUST return InvalidReques- server MUST return InvalidRequestEx-
tException ception
● If id does not exists and lid does not
exist, server MUST create new ob-
ject using that id (create)
● If id does not exists and lid exists,
server MUST throw InvalidReques-
tException (otherwise multiple root
level versions would become pos-
sible)
● If id exists, server MUST create a
new version of existing object
matching that id (version)

CreateOnly ● MAY be specified by client ● MUST be specified by client or else

server MUST return InvalidRequestEx-
● If unspecified Server MUST gener- ception
ate UUID URN
● MUST NOT exist or else server MUST
● If id does not exists, server MUST return ObjectExistsException
create new object using that id (cre-
ate)
● If id exists, server MUST return Ob-
jectExistsException

Table 2: Requirements for id and lid During SubmitObjects Protocol

714

715 3.1.1.4 Returns

716 This request returns a RegistryResponse.

717 3.1.1.5 Exceptions

718 ● A server MUST return an UnsupportedCapabilityException fault message if the request contains
719 a type that is an extension of types defined by ebRIM and if the server cannot support such ex-
720 tension.

721 3.1.2 Audit Trail Requirements

722 ● The server MUST create a single AuditableEvent object as follows:
regrep-core-rs-v4.0-os 25 January 2012
Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 44 of 95
723 ○ If RegistryObjects were created by the request, it contain a single Action sub-element with
724 eventType Created for all the RegistryObjects created during processing of the request

725 ○ If RegistryObjects were updated by the request, it contain a single Action sub-element with
726 eventType Updated for all the RegistryObjects updated during processing of the request

727 ● The server SHOULD create AuditableEvents after successfully processing the request in a separ-
728 ate transaction from the request

729 3.1.3 Sample SubmitObjectsRequest

730 The following simplified example shows a SubmitObjectsRequest that submits a single Organization ob-
731 ject to the server.

732
<lcm:SubmitObjectsRequest>
<rim:RegistryObjectList>
<rim:RegistryObject xsi:type="rim:OrganizationType" lid="${LOGICAL_ID}"
id="${ID}" ...>

...

</rim:RegistryObject>
</rim:RegistryObjectList>
</SubmitObjectsRequest>

733 3.2 The Update Objects Protocol

734 The UpdateObjectsRequest protocol allows a client to make partial updates to one or more RegistryOb-
735 jects that already exist in the server. This protocol enables partial update of RegistryObjects rather than a
736 complete replacement. A client SHOULD use the SubmitObjects protocol for complete replacement of
737 RegistryObjects.

738 A server MUST return InvalidRequestException fault message if the client attempts to update the id, lid or
739 objectType attribute of a RegistryObject.

740

Illustration 3: UpdateObjects Protocol

742 3.2.1 UpdateObjectsRequest

743 The UpdateObjectsRequest message is sent by a client to partially update existing RegistryObjects in the
744 server. An UpdateObjectsRequest identifies a set of RegistryObjects as target objects to be updated by
745 the request. It also specifies the update action that modifies each target object. Update actions may insert
746 a node within a target object, delete an existing node from a target object or update an existing node

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 45 of 95
747 within the target object. A node in the context of the UpdateObjects protocol is defined to be an XML
748 DOM node (typically an element or an attribute).

749 3.2.1.1 Syntax

<element name="UpdateObjectsRequest">
<complexType>
<complexContent>
<extension base="rs:RegistryRequestType">
<sequence>
<!-- Query and ObjectRefList select objects to update -->
<element name="Query" type="rim:QueryType" minOccurs="0" maxOccurs="1" />
<element ref="rim:ObjectRefList" minOccurs="0" maxOccurs="1" />

<!-- Specifies how to update selected objects -->

<element name="UpdateAction" type="tns:UpdateActionType"
minOccurs="1" maxOccurs="unbounded"/>
</sequence>
<attribute name="checkReferences" type="boolean" use="optional"
default="false"/>
<attribute name="mode" type="tns:mode" use="optional"
default="CreateOrReplace"/>
</extension>
</complexContent>
</complexType>
</element>

750 3.2.1.2 Description

751 ● Element Query - Specifies a query to be invoked. A server MUST use all objects that match the
752 specified query in addition to any other objects identified by the ObjectRefList element as targets
753 of the update action.

754 ● Element ObjectRefList - Specifies a collection of references to existing RegistryObject instances

755 in the server. A server MUST use all objects that are referenced by this element in addition to any
756 other objects identified by the Query element as targets of the update action.

757 ● Element UpdateAction – Specifies the details of how to update the target objects

758 ● Attribute checkReferences – Specifies the reference checking behavior expected of the server

759 ○ true - Specifies that a server MUST check updated objects and make sure that all references
760 via reference attributes and slots to other RegistryObjects are resolvable. If a reference does
761 not resolve then the server MUST return UnresolvedReferenceException

762 ○ false (default) – Specifies that a server MUST NOT check updated objects to make sure that
763 all references via reference attributes and slots to other RegistryObjects are resolvable. If a
764 reference does not resolve then the server MUST NOT return UnresolvedReferenceExcep-
765 tion

766 ● Attribute mode – Specifies the semantics for how the server should handle RegistryObjects being
767 updated in the server:

768 ○ CreateOrReplace (default) - If an object does not exist, server MUST return ObjectNotFoun-
769 dException. If an object already exists, server MUST update the existing object without creat-
770 ing a new version

771 ○ CreateOrVersion - If an object does not exist, server MUST return ObjectNotFoundException.
772 If an object already exists, server MUST create a new version of the existing object before
773 applying the requested update action

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 46 of 95
774 ○ CreateOnly – This mode does not apply to UpdateObjectsRequest. If specified, server MUST
775 return an InvalidRequestException

776 3.2.1.3 Returns

777 This request returns a RegistryResponse.

778 3.2.1.4 Exceptions

779 ● A server MUST return an UnsupportedCapabilityException fault message if the request contains
780 a type that is an extension of types defined by ebRIM and if the server cannot support such ex-
781 tension.

782 3.2.2 UpdateAction

783 An UpdateRequest contains one or more UpdateActions. Each UpdateObjectsRequest defines a specific
784 update action to be performed on each target object.

785 3.2.2.1 Syntax

<complexType name="UpdateActionType">
<annotation>
<documentation xml:lang="en">
</documentation>
</annotation>
<sequence>
<!-- Value for attribute or element -->
<element name="ValueHolder" type="rim:ValueType"
minOccurs="0" maxOccurs="1"/>
<!--
Value of selector is an XPATH expression that uniquely identifies
an attribute or an element within target documents.
-->
<element name="Selector" type="rim:QueryExpressionType"
minOccurs="1" maxOccurs="1"/>
</sequence>

<!--
Specifies whether to insert, update or delete a node from
target document.
-->
<attribute name="mode" use="required">
<simpleType>
<restriction base="NCName">
<enumeration value="Insert"/>
<enumeration value="Update"/>
<enumeration value="Delete"/>
</restriction>
</simpleType>
</attribute>
</complexType>

786 3.2.2.2 Description

787 ● Element Selector – Is a QueryExpressionType that contains the expression that identifies a node
788 of the resource representation to be updated.
789
790 The value of this element MUST conform to the queryLanguage specified in the queryLanguage
791 attribute of the Selector. A resource MUST generate an QueryException fault if the expression is
regrep-core-rs-v4.0-os 25 January 2012
Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 47 of 95
792 invalid. If the expression syntax is not valid with respect to the queryLanguage then a resource
793 SHOULD specify a fault detail of "InvalidExpressionSyntaxException". If the expression value is
794 not valid for the resource type then the resource SHOULD specify a fault detail of "InvalidExpres-
795 sionValueException".
796
797 A server MUST minimally support XPATH 1.0 as the queryLanguage for Selector element. The
798 scope of the XML document that is processed by the XPATH expression is the RegistryObject-
799 Type instance. A server MUST implicitly support the standard namespace prefixes used by Re-
800 gRep schemas (rim:, query:, rs:, lcm:, spi:) as a notational convenience. These standard
801 namespace prefixes should map to the latest version of the specification supported by the server.
802
803 An XPATH selector expression MUST be specified using the RegistryObject being updated as
804 the context node.
805
806 An XPATH selector expression may select an attribute or an element relative to the RegistryOb-
807 ject context node. If it selects an attribute then the ValueHolder element should use a ValueType
808 subtype for a primitive type (instead of AnyValueType) that corresponds to the primitive type for
809 the attribute (e.g. StringValueType). The ValueHolder/Value element's content shall contain the
810 attribute value.

811 ● Element ValueHolder - This element contains the value to be written to the target object. If the
812 mode attribute is "Insert" or "Update" then this element MUST be present. If the mode is "Delete"
813 then this element MUST NOT be present.

814 ● Attribute mode – This attribute specifies the semantics for how the server should update target
815 objects:

816 ○ Insert - Indicates that the value provided by ValueHolder MUST be added to the target object.
817 If the selector targets a repeated element (maxOccurs > 1), the node MUST be added at the
818 end. If the selector targets a non-repeated element (maxOccurrs = 1) that already exists, the
819 resource MUST generate an InvalidRequestException with a fault detail of NodeAlreadyExist-
820 sException. If the selector targets an existing item of a repeated element, the value provided
821 by ValueHolder MUST be added before the existing item.

822 ○ Update – Indicates that the node identified by selector MUST be replaced by value by the
823 ValueHolder in its place. If the selector resolves to nothing then there should be no change to
824 the target object.

825 ○ Delete - indicates that the node identified by selector MUST be deleted from the target object
826 if it is present.

827 3.2.3 Audit Trail Requirements

828 ● The server MUST create a single AuditableEvent object as follows:

829 ○ If RegistryObjects were updated by the request, it contain a single Action sub-element with
830 eventType Updated for all the RegistryObjects updated during processing of the request

831 ● The server SHOULD create AuditableEvents after successfully processing the request in a separ-
832 ate transaction from the request

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 48 of 95
833 3.2.4 Sample UpdateObjectsRequest
834 The following example shows an UpdateObjectsRequest which updates the Name element within a Per-
835 sonType instance with the Name element specified by the Value element within UpdateAction. The Se-
836 lector element uses an XPATH expression to select the Name element node within the Person objects
837 identified as target of update in the ObjectRefList. The context node of the XPATH expression is the Re-
838 gistryObject element for the PersonType instance. The target objects could also have been chosen by a
839 Query element.
<UpdateObjectsRequest ...>
<rim:ObjectRefList>
<rim:ObjectRef id="urn:acme:person:Danyal"/>
</rim:ObjectRefList>
<UpdateAction mode="Update">
<Value xsi:type="rim:AnyValueType">
<rim:Name>
<rim:LocalizedString xml:lang="en-US" value="Danny"/>
</rim:Name>
</Value>
<Selector xsi:type="rim:StringQueryExpressionType"
queryLanguage="urn:oasis:names:tc:ebxml-regrep:QueryLanguage:XPath">

<rim:Value>./rim:Name</rim:Value>
</Selector>
</UpdateAction>
</UpdateObjectsRequest>

840 3.3 RemoveObjects Protocol

841 The Remove Objects protocol allows a client to remove or delete one or more RegistryObject instances
842 from the server.

843 A client initiates the RemoveObjects protocol by sending a RemoveObjectsRequest message to the Life-
844 cycleManager endpoint.

845 The LifecycleManager sends a RegistryResponse back to the client as response.

846

Illustration 4: RemoveObjects Protocol

848 3.3.1 RemoveObjectsRequest

849 The RemoveObjectsRequest message is sent by a client to remove one or more existing RegistryObjects
850 from the server.

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 49 of 95
851 3.3.1.1 Syntax
<element name="RemoveObjectsRequest">
<complexType>
<complexContent>
<extension base="rs:RegistryRequestType">
<sequence>
<element name="Query" type="rim:QueryType"
minOccurs="0" maxOccurs="1" />
<element ref="rim:ObjectRefList" minOccurs="0" maxOccurs="1" />
</sequence>
<attribute name="checkReferences" type="boolean" use="optional"
default="false"/>
<attribute name="deleteChildren" type="boolean" use="optional"
default="false"/>
<attribute name="deletionScope" type="rim:objectReferenceType"
use="optional" default="urn:oasis:names:tc:ebxml-
regrep:DeletionScopeType:DeleteAll"/>
</extension>
</complexContent>
</complexType>
</element>

852 3.3.1.2 Description

853 ● Attribute checkReferences – Specifies the reference checking behavior expected of the server

854 ○ true - Specifies that a server MUST check objects being removed and make sure that there
855 are no references to them from other objects via reference attributes and slots. If a reference
856 exists then the server MUST return ReferencesExistsException

857 ○ false (default) – Specifies that a server MUST NOT check objects being removed to make
858 sure that there are no references to them from other objects via reference attributes and
859 slots. If a reference exists then the server MUST NOT return ReferencesExistsException

860 ● Attribute deleteChildren – This attribute specifies whether or not to delete children of the objects
861 being deleted according to the following behavior:

862 ○ false – Specifies the server MUST NOT delete the children of objects that are specified to be
863 deleted

864 ○ true – Specifies the server MUST delete children of objects being deleted if and only if those
865 children are not children of any other parent objects

866 ● Attribute deletionScope - This attribute specifies the scope of impact of the RemoveObjects-
867 Request. The value of the deletionScope attribute MUST be a reference to a ClassificationNode
868 within the canonical DeletionScopeType ClassificationScheme as described in ebRIM. A server
869 MUST support the deletionScope types as defined by the canonical DeletionScopeType Classific-
870 ationScheme. The canonical DeletionScopeType ClassificationScheme may be extended by
871 adding additional ClassificationNodes to it.
872
873 The following canonical ClassificationNodes are defined for the DeletionScopeType Classifica-
874 tionScheme:

875 ○ DeleteRepositoryItemOnly - Specifies that the server MUST delete the RepositoryItem for the
876 specified ExtrinsicObjects but MUST NOT delete the specified ExtrinsicObjects

877 ○ DeleteAll (default) - Specifies that the request MUST delete both the RegistryObject and the
878 RepositoryItem (if any) for the specified objects
regrep-core-rs-v4.0-os 25 January 2012
Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 50 of 95
879 ● Element Query - Specifies a query to be invoked. A server MUST remove all objects that match
880 the specified query in addition to any other objects identified by the ObjectRefList element.

881 ● Element ObjectRefList - Specifies a collection of references to existing RegistryObject instances

882 in the server. A server MUST remove all objects that are referenced by this element in addition to
883 any other objects identified by the Query element.

884 3.3.1.3 Returns:

885 This request returns a RegistryResponse.

886 3.3.1.4 Exceptions:

887 In addition to the exceptions common to all requests, the following exceptions MAY be returned:

888 ● UnresolvedReferenceException - Indicates that the requestor referenced an object within the re-
889 quest that was not resolved during the processing of the request.

890 ● ReferencesExistException - Indicates that the requestor attempted to remove a RegistryObject

891 while references to it still exist. Note that it is valid to remove a RegistryObject and all RegistryOb-
892 jects that refer to it within the same request. In such cases the ReferencesExistException MUST
893 not be thrown.

894 3.3.2 Audit Trail Requirements

895 ● The server MUST create a single AuditableEvent object as follows:

896 ○ If RegistryObjects were removed by the request, it contain a single Action sub-element with
897 eventType Deleted for all the RegistryObjects removed during processing of the request

898 ● The server SHOULD create AuditableEvents after successfully processing the request in a separ-
899 ate transaction from the request

900 3.3.3 Sample RemoveObjectsRequest

901 The following is a sample RemoveObjectsRequest to remove an Object by its id.
<lcm:RemoveObjectsRequest ...>
<rim:ObjectRefList>
<rim:ObjectRef id="urn:acme:Person:Danyal"/>
</rim:ObjectRefList>
</lcm:RemoveObjectsRequest>

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 51 of 95
902 4 Version Control
903 This section describes the version control features of the ebXML RegRep.

904 Versioning of a RegistryObjectType instance is the process of updating the object in such a way that the
905 original instance remains unchanged while a new instance is created as a new version of the original in-
906 stance. Any specific version of an object may itself be versioned. Thus in general the versions of an ob-
907 ject form a tree structure referred to as the Version Tree for that object.

908 A Version Tree for an object is defined to be a tree structure where:

909 ● There is a single root node for the tree

910 ● The root is the original version

911 ● Each non-root node in the tree is a version of the object

912 ● Each version is created from a parent version and is represented in the version tree as a child
913 node of the node representing the parent version node for that version

Illustration 5: A visual example of a version tree

915 Illustration 5 visualizes the version tree concept. In this non-normative example the object TestRegister
916 has 8 versions. Each node's version is identified by the parenthesized string suffix like “(1.2.2)”. Version 1
917 is the original version. Version 1 was versioned twice to create versions 1.1 and 1.2. Version 1.1 was ver-
918 sioned twice to create versions 1.1.1 and 1.1.2. Version 1.2 was versioned twice to create versions 1.2.1
919 and 1.2.2. Version 1.2.1 was versioned once to create version 1.2.1.1. Note that this example uses a ver-
920 sion naming convention for ease of understanding only. This specification does not prescribe a specific
921 version naming convention for server to use when assigning version names.

922 The terms “logical object” or “logical RegistryObject” are used to refer to all version of a RegistryObject in
923 a version independent manner. The terms “object version” or “RegistryObject version” are used to refer to
924 a specific version of the logical object. The terms “RegistryObject instance” and “RegistryObjectType in-
925 stance” imply a specific object version.

926 Illustration 5 visualizes a single logical object TestRegister with 8 object versions.

927 4.1 Version Controlled Resources

928 Version controlled resources are resources that support versioning capability.

929 All repository items in an ebXML RegRep are implicitly version-controlled resources as defined by section
930 2.2.1 of [DeltaV]. No explicit action is required to make them a version-controlled resource.
regrep-core-rs-v4.0-os 25 January 2012
Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 52 of 95
931 Instances of RegistryObjectType types are also implicitly version-controlled resources. The only excep-
932 tions are those sub-types of RegistryObjectType that are composed 1 types and their instances do not
933 have independent lifecycles that are separate from the lifecycle of their parent objects. Some example of
934 such composed types are:

935 ● ClassificationType

936 ● ExternalIdentifierType

937 ● ExternalLinkType

938 ● ServiceEndpointType

939 A server MAY further limit specific non-composed types from being version-controlled resources based
940 upon server specific policies.

941 4.2 Versioning and Id Attribute

942 Each object version of a logical RegistryObject is a unique object and as such has its own unique value
943 for its id attribute as defined by [regrep-rim-v4.0].

944 4.3 Versioning and Lid Attribute

945 A RegistryObject instance MUST have a Logical ID (LID) defined by its “lid” attribute to identify the logical
946 RegistryObject of which it is a version. All versions of a logical RegistryObject have the same “lid” attrib-
947 ute value. Note that this is in contrast with the “id” attribute that MUST be unique for each version of the
948 same logical RegistryObject. A client may refer to the logical RegistryObject in a version independent
949 manner using its LID.

950 4.4 Version Identification for RegistryObjectType

951 A RegistryObjectType instance MUST have a VersionInfo element whose type is the VersionInfoType
952 type defined by ebRIM. The VersionInfo element identifies the version information for that RegistryObject-
953 Type instance. The versionName attribute of the VersionInfo element identifies the version name for a
954 specific version of a logical object. A server MUST not allow two versions of the same logical object to
955 have the same versionName attribute value within its VersionInfo element.

956 4.5 Version Identification for RepositoryItem

957 When a RegistryObject is an ExtrinsicObject with an associated repository item, the version identification
958 for the repository item is distinct from the version identification for the ExtrinsicObject.

959 An ExtrinsicObject that has an associated repository item MUST have a contentVersionInfo element
960 whose type is VersionInfoType defined by ebRIM. The contentVersionInfo attributes identifies the version
961 information for that repository item instance.

962 4.5.1 Versioning of RegistryObjectType

963 This section describes the versioning of all RegistryObjectType types with the exception of ExtrinsicOb-
964 jectType which is defined in a separate section.

965 The following rules apply to versioning of all RegistryObjectType instances that are not instances of Ex-
966 trinsicObjectType type. It assumes that versioning is enabled for such RegistryObjectType types:

1
Composed object types are identified in class diagrams in [regrep-rim-v4.0] as classes with composi-
tion or “solid diamond” relationship with a RegistryObject type.
regrep-core-rs-v4.0-os 25 January 2012
Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 53 of 95
 967 ● A server MUST create a new version of a version-controlled, non-composed RegistryObjectType
968 instance in the following cases:

969 ○ An existing object is replaced using the submitObjects protocol with mode of CreateOrVer-
970 sion

971 ○ An existing object is updated using the updateObjects protocol with mode of CreateOrVersion

972 ● A server MUST NOT create a new version of a composed RegistryObjectType instance when it is
973 updated.

974 ● When creating a new version for a non-composed RegistryObjectType instance, a server MUST
975 create new logical objects for any composed logical objects within the new version of the com-
976 posed object. Any such new logical object for composed objects MUST have a new server gener-
977 ated universally unique id and lid attribute.

978 4.5.2 Versioning of ExtrinsicObjectType

979 The ExtrinsicObjectType type requires special consideration for versioning because it may have an asso-
980 ciated RepositoryItem which is versioned independently from the ExtrinsicObjectType instance.

981 The following rules apply to versioning of ExtrinsicObjectType instances assuming that a server has ver-
982 sioning enabled for the ExtrinsicObjectType type:

983 ● A server MUST create a new version of an existing ExtrinsicObjectType instance and assign it a
984 new unique versionName within its VersionInfo element when either the ExtrinsicObjectType in-
985 stance or its RepositoryItem are updated using the submitObjects or updateObjects protocol and
986 the mode is CreateOrVersion

987 ○ A server MUST create a new version of an ExtrinsicObjectType instance and assign it a new
988 unique versionName within its VersionInfo element when the previous version had a Reposit-
989 oryItem and the new version does not have one (RepositoryItem was deleted).

990 ○ A server MUST create a new version of an ExtrinsicObjectType instance and assign it a new
991 unique versionName within its VersionInfo element when the previous version did not have
992 RepositoryItem and the new version has one (RepositoryItem was added). In such cases the
993 server MUST also create a new version of the RepositoryItem and assign it a new unique ver-
994 sionName within the ContentVersionInfo element.

995 ○ A server MUST create a new version of the RepositoryItem for an existing ExtrinsicObject-
996 Type instance and assign it a new unique versionName within the ContentVersionInfo ele-
997 ment when the RepositoryItem is updated using the submitObjects or updateObjects protocol
998 and the mode is CreateOrVersion

999 4.6 Versioning and References

1000 An object reference from a RegistryObjectType instance references a specific version of the referenced
1001 RegistryObjectType instance. When a server creates a new version of a referenced RegistryObjectType
1002 instance it MUST NOT move references from other objects from the previous version to the new version
1003 of the referenced object. Clients that wish to always reference the latest versions of an object MAY use
1004 the “dynamic reference” defined in ebRIM feature to always reference the latest version.

1005 A special case is when a SubmitObjectsRequest contains an object that is being versioned by the server
1006 and the request contains other objects that reference the object being versioned. In such case, the server
1007 MUST update all references within the submitted objects to the object being versioned such that those
1008 objects now reference the new version of the object being created by the request.

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 54 of 95
1009 4.7 Versioning of RegistryPackages
1010 When a server creates a new version of a RegistryPackageType instance, it MUST implicitly make all
1011 members of the old version also be members of the new version. This requires that the server MUST
1012 make a copy of all HasMember Associations in which the old version of the RegistryPackage is the
1013 sourceObject as follows:

1014 ● The copied Associations MUST be new versions of their original Association (MUST have the
1015 same lid)

1016 ● The sourceObject of the copied Associations MUST reference the new version of the RegistryP-
1017 ackage rather than the older version

1018

1020 4.8 Versioning and RegistryPackage Membership

1021 A RegistryPackage MUST NOT contain more than version of the same logical object as its member.

1022 ● A server MUST return an InvalidRequestException fault message if a client attempts to publish
1023 more than one version of the same logical object as member of the same RegistryPackage in-
1024 stance

1025

1026 4.9 Inter-version Association

1027 Each RegistryObject node in the version tree of a logical object except for the root version MUST be
1028 linked to the RegistryObject node in the version tree that was its immediate predecessor (previous ver-
1029 sion).

1030 ● A server MUST automatically link each new version in the version tree for a RegistryObject to its
1031 predecessor using an Association between the two versions

1032 ● The type attribute value of the Association MUST reference the canonical AssociationType “Su-
1033 persedes”

1034 ● The sourceObject attribute value of the Association MUST reference the new version

1035 ● The targetObject attribute value of the Association MUST reference the old version

1036 Note that this section is functionally equivalent to the predecessor-set successor-set elements of the Ver-
1037 sion Properties as defined by [DeltaV].

1038 4.10 Version Removal

1039 Specific versions of a logical object MAY be deleted using the RemoveObjects protocol by specifying the
1040 version by its unique id.

1041 ● A server MAY allow authorized clients to remove specified versions of a RegistryObject

1042 ● A server MAY prune older versions of RegistryObjects based upon server specific administrative
1043 policies in order to manage storage resources

1044 ● When a non-leaf version within a version tree is deleted, a server MUST implicitly delete the en-
1045 tire version sub-tree under that non-leaf version such that no versions created directly or indirectly
1046 from the specified remain in the registry
regrep-core-rs-v4.0-os 25 January 2012
Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 55 of 95
1047 4.11 Locking and Concurrent Modifications
1048 This specification does not define explicit checkin and checkout capabilities as defined by [DeltaV]. A
1049 server MAY support such features in an implementation specific manner.

1050 This specification does not prescribe a locking model. An implementation may choose to support a lock-
1051 ing model in an implementation specific manner. A future specification may address these capabilities.

1052 4.12 Version Creation

1053 The server manages creation of new version of a version-controlled resource automatically. A server that
1054 supports versioning MUST implicitly create a new version for the resource if an existing version of the re-
1055 source is updated via a SubmitObjectsRequest or UpdateObjectsRequest when the mode attribute value
1056 is CreateOrVersion. A server MUST update the existing version of a resource without creating a new ver-
1057 sion when the mode attribute is set to CreateOrReplace.

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 56 of 95
1058 5 Validator Interface
1059 The Validator interface allows the validation of objects published to the server. The interface may be used
1060 by clients to validate objects already published to the server or may be used by the server to validate ob-
1061 jects during the processing of the submitObjects or updateObjects protocol

1062 A server MUST implement the Validator interface as an endpoint. The Validator interface validates ob-
1063 jects using Validator Plugins specific to the type of object being validated.

1064 5.1 ValidateObjects Protocol

1065 The ValidateObjects protocol is initiated by sending an ValidateObjectsRequest message to the Validator
1066 endpoint.

Illustration 6: ValidateObjects Protocol

1067 The Validator endpoint sends an ValidateObjectsResponse back as response. The ValidateObjects-
1068 Response contains information on whether the objects were valid and if invalid objects were found it in-
1069 cludes any validation errors that were encountered.

1070 5.1.1 ValidateObjectsRequest

1071 The ValidateObjectsRequest message initiates the validateObjects protocol and specifies the objects that
1072 need to be validated.

1073 5.1.1.1 Syntax

<element name="ValidateObjectsRequest">
<complexType>
<complexContent>
<extension base="rs:RegistryRequestType">
<sequence>
<element name="Query" type="rim:QueryType"
minOccurs="0" maxOccurs="1" />
<element ref="rim:ObjectRefList" minOccurs="0" maxOccurs="1" />
<element name="OriginalObjects" type="rim:RegistryObjectListType"
minOccurs="1" maxOccurs="1"/>
<element name="InvocationControlFile"
type="rim:ExtrinsicObjectType"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
</element>

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 57 of 95
1074 5.1.1.2 Example
1075 The following example shows a client request to validate a specified WSDL file. It assumes that the server
1076 will be configured with a Validator plugin for WSDL files. It also assumes that the server will specify Ori-
1077 ginalObjects and InvocationControlFile elements when it relays the request to the appropriate Validator
1078 plugin.
<spi:ValidateObjectsRequest ...>
<rim:ObjectRefList>
<rim:ObjectRef id="urn:acme:wsdl:purchaseOrder.wsdl"/>
</rim:ObjectRefList>
</ValidateObjectsRequest>

1079 5.1.1.3 Description

1080 ● Element InvocationControlFile – Specifies an ExtrinsicObject that is used to control the validation
1081 process in a type specific manner. See Canonical XML Validator plugin for an example. This ele-
1082 ment MAY be specified by server when sending the request to the Validator plugin if the Validator
1083 plugin requires an invocation control file. It SHOULD NOT be specified by the client.

1084 ● Element ObjectRefList - Specifies a collection of references to existing RegistryObject instances

1085 in the server. A server MUST validate all objects that are referenced by this element. This ele-
1086 ment is typically used when a client initiates the validateObjects protocol.

1087 ● Element OriginalObjects - Specifies a collection of RegistryObject instances. A server MUST val-
1088 idate all objects that are contained in this element. This element is typically used when a server
1089 initiates the validateObjects protocol during the processing of a submitObjects or updateObjects
1090 protocol request or when it is delegating a client initiated validateObjects protocol request to a
1091 Validator plugin.

1092 ● Element Query - Specifies a query to be invoked. A server MUST validate all objects that match
1093 the specified query. This element is typically used when a client initiates the validateObjects pro-
1094 tocol.

1095 5.1.1.4 Response

1096 This request returns ValidateObjectsResponse as response.

1097 5.1.1.5 Exceptions

In addition to the common exceptions, the following exceptions MAY be returned:

● ValidationException: signifies that an exception was encountered during the validateObjects operation

1098 5.1.2 ValidateObjectsResponse

1099 Currently ValidateObjectsResponse is a simple extension to RegistryResponseType and does not define
1100 additional attributes or elements.

1101 5.2 Validator Plugins

1102 Validator plugins allow a server to use specialized extension modules to validate specific types of objects
1103 during the processing of a SubmitObjectsRequest, UpdateObjectsRequest or a ValidateObjectsRequest.

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 58 of 95
1104 A specific instance of a Validator plugin is designed and configured to validate a specific type of object.
1105 For example, the canonical XML Validator plugin is designed and configured to validate XML Objects us-
1106 ing Schematron documents as InvocationControlFile.

1107 5.2.1 Validator Plugin Interface

1108 A Validator plugin implements the Validator interface. The server's Validator endpoint SHOULD delegate
1109 a validateObjects operation to any number of Validator plugins using the following algorithm:

1110 ● The server selects the RegistryObjects that are the target of the validateObjects operations using
1111 the <spi:Query> and <rim:ObjectRefList> elements. Any objects specified by the OriginalObjects
1112 element MUST be ignored by the server.

1113 ● The server partitions the set of target objects into multiple sets based upon the objectType attrib-
1114 ute value for the target objects

1115 ● The server determines whether there is a Validator plugin configured for each objectType for
1116 which there is a set of target objects

1117 ● For each set of target objects that share a common objectType and for which there is a con-
1118 figured Validator plugin, the server MUST invoke the Validator plugin. The Validator plugin invoc-
1119 ation MUST specify the target objects for that set using the OriginalObjects element. The server
1120 MUST NOT specify <spi:Query> and <rim:ObjectRefList> elements when invoking validateOb-
1121 jects operation on a Validator plugin

1122 ● Each Validator plugin MUST process the ValidateObjectsRquest and return a ValidateObjects-
1123 Response or fault message to the server's Validator endpoint.

1124 ● The server's Validator endpoint MUST then combine the results of the individual ValidateObjects-
1125 Request to Validator plugins into a single unified ValidateObjectsResponse and return it to the cli-
1126 ent.

1127 5.2.2 Canonical XML Validator Plugin

1128 The canonical XML Validator plugin is a validator plugin that validates XML content using a Schematron
1129 file as InvocationControlFile. The Schematron file specifies validation rules using [Schematron] language
1130 to validate XML content. The server may configure the canonical XML Validator plugin such that it is in-
1131 voked with an appropriate schematron file as InvocationControlFile based upon the objectType of the ob-
1132 ject being validated.

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 59 of 95
1133 6 Cataloger Interface
1134 The Cataloger interface allows a client to catalog or index objects already in the server. The interface may
1135 be used by clients to catalog objects already published to the server or may be used by the server to
1136 catalog objects during the processing of the submitObjects or updateObjects protocol .

1137 A server MUST implement the Cataloger interface as an endpoint. The Cataloger interface catalogs ob-
1138 jects using Cataloger Plugins specific to the type of object being cataloged.

1139 6.1 CatalogObjects Protocol

1140 A client catalogs RegistryObjects residing in the server using the CatalogObjects protocol supported by
1141 the catalogObjects operation of the Cataloger interface.

1142 The CatalogObjects protocol is initiated by sending an CatalogObjectsRequest message to the Cataloger
1143 endpoint.

1144

Illustration 7: CatalogObjects Protocol

1146 The Cataloger endpoint sends a CatalogObjectsResponse back to the client as response.

1147 6.1.1 CatalogObjectsRequest

1148 The CatalogObjectsRequest message initiates the catalogObjects protocol and specifies the objects that
1149 need to be cataloged.

1150 6.1.1.1 Syntax

<element name="CatalogObjectsRequest">
<complexType>
<complexContent>
<extension base="rs:RegistryRequestType">
<sequence>
<element name="Query" type="rim:QueryType"
minOccurs="0" maxOccurs="1" />
<element ref="rim:ObjectRefList" minOccurs="0" maxOccurs="1" />
<element name="OriginalObjects" type="rim:RegistryObjectListType"
minOccurs="0" maxOccurs="1"/>
<element name="InvocationControlFile"
type="rim:ExtrinsicObjectType"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 60 of 95
 </extension>
</complexContent>
</complexType>
</element>

1151 6.1.1.2 Example

1152 The following example shows a client request to catalog a specified WSDL file. It assumes that the server
1153 will be configured with a Cataloger plugin for WSDL files. It also assumes that the server will specify Ori-
1154 ginalObjects and InvocationControlFile elements when it relays the request to the appropriate Cataloger
1155 plugin.
<spi:CatalogObjectsRequest ...>
<rim:ObjectRefList>
<rim:ObjectRef id="urn:acme:wsdl:purchaseOrder.wsdl"/>
</rim:ObjectRefList>
</CatalogObjectsRequest>

1156 6.1.1.3 Description

1157 ● Element InvocationControlFile – Specifies an ExtrinsicObject that is used to control the cataloging
1158 process in a type specific manner. See Canonical XML Catalogor plugin for an example. This ele-
1159 ment MAY be specified by server when sending the request to the Cataloger plugin if the Cata-
1160 loger plugin requires an an invocation control file. It SHOULD NOT be specified by the client.

1161 ● Element ObjectRefList - Specifies a collection of references to existing RegistryObject instances

1162 in the server. A server MUST catalog all objects that are referenced by this element. This element
1163 is typically used when a client initiates the catalogObjects protocol.

1164 ● Element OriginalObjects - Specifies a collection of RegistryObject instances. A server MUST

1165 catalog all objects that are contained in this element. This element is typically used when a server
1166 initiates the catalogObjects protocol during the processing of a submitObjects or updateObjects
1167 protocol request or when it is delegating a client initiated catalogObjects protocol request to a
1168 Cataloger plugin.

1169 ● Element Query - Specifies a query to be invoked. A server MUST catalog all objects that match
1170 the specified query. This element is typically used when a client initiates the catalogObjects pro-
1171 tocol.

1172

1173 6.1.1.4 Response

1174 This request returns CatalogObjectsResponse as response.

1175 6.1.1.5 Exceptions

In addition to common exceptions, the following exceptions MAY be returned:

● CatalogingException: signifies that an exception was encountered during the catalogObjects operation

1176 6.1.2 CatalogObjectsResponse

1177 The CatalogObjectsResponse message is sent by the Cataloger endpoint in response to an CatalogOb-
1178 jectsRequest.

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 61 of 95
1179 6.1.2.1 Syntax
<element name="CatalogObjectsResponse">
<complexType>
<complexContent>
<extension base="rs:RegistryResponseType">
</extension>
</complexContent>
</complexType>
</element>

1180 6.1.2.2 Example

1181 The following example shows a CatalogObjectsResponse sent by a server to the client in response to a
1182 CatalogedObjectRequest. It shows that the Cataloger augmented the Original object with a new Slot that
1183 catalogs the target namespace used by the WSDL file.

1184
<CatalogObjectsResponse status="urn:oasis:names:tc:ebxml-
regrep:ResponseStatusType:Success">
<rim:RegistryObjectList>
<rim:RegistryObject xsi:type="rim:ExtrinsicObjectType"
mimeType="text/xml"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Submitted"
objectType="urn:oasis:names:tc:ebxml-
regrep:ObjectType:RegistryObject:ExtrinsicObject:XML:WSDL"
lid="urn:acme:wsdl:purchaseOrder.wsdl"
id="urn:acme:wsdl:purchaseOrder.wsdl">
<rim:Slot
name="urn:oasis:names:tc:ebxml-
regrep:profile:wsdl:slot:targetNamespace">
<rim:SlotValue xsi:type="rim:StringValueType">
<rim:Value>urn:acme:Service:PurchaseOrder</rim:Value>
</rim:SlotValue>
</rim:Slot>
<rim:RepositoryItem>...binary encoded content...</rim:RepositoryItem>
</rim:RegistryObject>
</rim:RegistryObjectList>
</CatalogObjectsResponse>

1185 6.1.2.3 Description

1186 In addition to elements and attributes defined by RegistryResponseType the following are defined:

1187 ● Element RegistryObjectList (Inherited) – Contains the RegistryObjects that are produced as out-
1188 put of the catalogObjects operation. Typically this list contains the objects that were input to the
1189 catalogObjects operation, as well as new objects that were the output of the catalogObjects oper-
1190 ation. The input objects MAY be modified by the cataloger as a result of the catalogObjects oper-
1191 ation.

1192 ○ A cataloger MUST create AssociationType instance between the source object for the cata-
1193 logObjects operation (specified by OriginalObjects element in CatalogRequest) and each of
1194 the cataloged RegistryObjectType instances generated by the cataloger. Each such Associ-
1195 ationType instance

1196 ■ MUST have its type attribute reference the canonical AssociationType
1197 “urn:oasis:names:tc:ebxml-regrep:AssociationType:HasCatalogedMetadata”

1198 ■ MUST have its sourceObject attribute reference the source object for the catalogObjects
1199 operation

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 62 of 95
1200 ■ MUST have its targetObject attribute reference a cataloged RegistryObjectType instance
1201 generated by the cataloger

1202 ○ A cataloger SHOULD assign the same accessControlPolicy to cataloged objects as their
1203 source object. A cataloger MAY use a different strategy for assigning access control policy to
1204 cataloged objects.

1205 ○ A server MUST delete all cataloged metadata generated by a cataloger when the source ob-
1206 ject is deleted.

1207 ○ A server MUST update all cataloged metadata generated by a cataloger when the source ob-
1208 ject is updated without creating a new version.

1209 6.2 Cataloger Plugins

1210 Cataloger plugins allow a server to use specialized extension modules to catalog specific types of objects
1211 during the processing of a SubmitObjectsRequest, UpdateObjectsRequest or a CatalogObjectsRequest.

1212 A specific instance of a Cataloger plugin is designed and configured to catalog a specific type of object.
1213 For example, the canonical XML Cataloger plugin is designed and configured to catalog XML Objects us-
1214 ing XSLT documents as InvocationControlFile.

1215 6.2.1 Cataloger Plugin Interface

1216 A Cataloger plugin implements the Cataloger interface. The server's Cataloger endpoint SHOULD deleg-
1217 ate a catalogObjects operation to any number of Cataloger plugins using the following algorithm:

1218 ● The server selects the RegistryObjects that are the target of the catalogObjects operations using
1219 the <spi:Query> and <rim:ObjectRefList> elements. Any objects specified by the OriginalObjects
1220 element MUST be ignored by the server.

1221 ● The server partitions the set of target objects into multiple sets based upon the objectType attrib-
1222 ute value for the target objects

1223 ● The server determines whether there is a Cataloger plugin configured for each objectType for
1224 which there is a set of target objects

1225 ● For each set of target objects that share a common objectType and for which there is a con-
1226 figured Cataloger plugin, the server MUST invoke the Cataloger plugin. The Cataloger plugin in-
1227 vocation MUST specify the target objects for that set using the OriginalObjects element. The
1228 server MUST NOT specify <spi:Query> and <rim:ObjectRefList> elements when invoking cata-
1229 logObjects operation on a Cataloger plugin

1230 ● Each Cataloger plugin MUST process the CatalogObjectsRquest and return a CatalogObjects-
1231 Response or fault message to the server's Cataloger endpoint.

1232 ● The server's Cataloger endpoint MUST then combine the results of the individual CatalogObjects-
1233 Request to Cataloger plugins and commit these objects as part of the transaction associated with
1234 the request. It MUST then combine the individual CatalogObjectsResponse messages into a
1235 single unified CatalogObjectsResponse and return it to the client.

1236 6.2.2 Canonical XML Cataloger Plugin

1237 The canonical XML Cataloger plugin is a Cataloger plugin that catalogs XML content using an XSLT file
1238 as InvocationControlFile. The XSLT file specifies transformations rules using [XSLT] language to catalog
1239 XML content. The server may configure the canonical XML Cataloger plugin such that it is invoked with
1240 an appropriate XSLT file as InvocationControlFile based upon the objectType of the object being cata-
1241 loged.
regrep-core-rs-v4.0-os 25 January 2012
Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 63 of 95
1242 An XSLT file used as InvocationControlFile with the Canonical XML Cataloger MUST meet the following
1243 constraints:

1244 ● Support an ExtrinsicObject as primary input

1245 ● Support an XML RepositoryItem for the ExtrinsicObject object as a secondary input

1246 ● The secondary input is specified using an <xsl:param> with name “repositoryItem” and with value
1247 that is the id of the ExtrinsicObject for which it is a RepositoryItem

1248 A server MUST implement the Canonical XML Cataloger with the following constraints:

1249 ● Uses an XSLT processor with the XSLT file specified as InvocationControlFile

1250 ● Specifies the ExtrinsicObject being cataloged as the primary input to the XSLT processor

1251 ● Specifies the RepositoryItem for the ExtrinsicObject object being cataloged by setting the para-
1252 meter named “repositoryItem” with a value that is the id of the ExtrinsicObject for which it is a Re-
1253 positoryItem

1254 ● Resolves references to the RepositoryItem via the $repositoryItem parameter value within the
1255 XSLT file specified as InvocationControlFile

1256

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 64 of 95
1257 7 Subscription and Notification
1258 A client MAY subscribe to events that transpire in the server by creating a Subscription. A server support-
1259 ing Subscription and Notification feature MUST deliver a Notification to the subscriber when an event
1260 transpires that matches the event selection criteria specified by the client.

1261 7.1 Server Events

1262 Activities within the server result in events. [regrep-rim-v4.0] defines the AuditableEvent element, in-
1263 stances of which represent server events. A server creates AuditableEvent instances during the pro-
1264 cessing of client requests.

1265 7.1.1 Pruning of Events

1266 A server MAY periodically prune AuditableEvents in order to manage its resources. It is up to the server
1267 when such pruning occurs. A server SHOULD perform such pruning by removing the older Audit-
1268 ableEvents first.

1269 7.2 Notifications

1270 A Notification message is used by the server to notify clients of events they have subscribed to. A Notific-
1271 ation contains the RegistryObjects, or references to the RegistryObjects, that are affected by the event for
1272 which the Notification is being sent, based upon the notificationOption within the DeliveryInfo for the sub-
1273 scription.

1274 Details for the Notification element are defined in [regrep-rim-v4.0].

1275 7.3 Creating a Subscription

1276 A client MAY create a subscription within a server if it wishes the server to send it a Notification when a
1277 specific type of event transpires. A client creates a subscription by submitting a rim:SubscriptionType in-
1278 stance to the server using the standard SubmitObjects protocol.

1279 Details for the rim:SubscriptionType are defined in [regrep-rim-v4.0].

1280 7.3.1 Subscription Authorization

1281 A deployment MAY use custom Access Control Policies to decide which users are authorized to create a
1282 subscription and to what events. A server MUST return an AuthorizationException in the event that an un-
1283 authorized user submits a Subscription to a server.

1284 7.3.2 Subscription Quotas

1285 A server MAY use server specific policies to decide an upper limit on the number of Subscriptions a user
1286 is allowed to create. A server SHOULD return a QuotaExceededException in the event that an authorized
1287 user submits more Subscriptions than allowed by their server-specific quota.

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 65 of 95
1288 7.3.3 Subscription Expiration
1289 Each subscription MAY define a startTime and endTime attribute which determines the period within
1290 which a Subscription is valid. If startTime is unspecified then a server MUST set it to the time of submis-
1291 sion of the subscription. If endTime is unspecified then the server MUST choose a default value based on
1292 its policies.

1293 Outside the bounds of the valid period, a Subscription MAY exist in an expired state within the server. A
1294 server MAY remove an expired Subscription at any time.

1295 A server MUST NOT deliver notifications for an event to an expired Subscriptions. An expired Subscrip-
1296 tion MAY be renewed by updating the startTime and / or endTime for the Subscription using the
1297 UpdateObjects protocol.

1298 7.3.4 Event Selection

1299 A client MUST specify a Selector element within the Subscription to specify its criteria for selecting events
1300 of interest. The Selector element is of type rim:QueryType and specifies an parameterized query to be in-
1301 voked with specified query parameters.

1302 A server MUST process AuditableEvents and determine which Subscriptions match the event using the
1303 algorithm illustrated by the following pseudo-code fragment:

1304
//Get objects that match selector query
List<RegistryObjectType> objectsOfInterest =
getObjectsMatchingSelectorQuery(selectorQuery);

if (objectsOfInterest.size() > 0) {

//Now get AuditableEvents that affected objectsOfInterest

//MUST not include AuditableEvents that have already been delivered
//to this subscriber
List<RegistryObjectType> eventsOfInterest =
getEventsOfInterest(objectsOfInterest);

if (eventsOfInterest.size() > 0) {
//Now create Notification on objectsOfInterest.
//Notification will include eventsOfInterest that only include objects
//that are affected by the event and are also in objectsOfInterest
NotificationType notification = createNotification(
objectsOfInterest, eventsOfInterest);

//Now send notification using info in DeliveryInfo

sendNotification(notification);
}
}

1305

1306 ● Objects of interest MUST be those objects that match the selector query for the subscription

1307 ● Events of interest MUST have affected at least one object of interest

1308 ● Events of interest MUST contain all objects of interest (or references to them) that were affected
1309 by the event

1310 ● Events of interest MUST NOT contain an object or reference to an object that is not an object of
1311 interest

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 66 of 95
1312 7.4 Event Delivery
1313 A client MAY specify zero or more DeliveryInfo elements within the Subscription to specify how the server
1314 should deliver events matching the subscription to the client. The DeliveryInfo element MUST include a
1315 NotifyTo element which specifies an EndPoint Reference (EPR) as defined by [WSA-CORE]. The Noti-
1316 fyTo element contains a <wsa:Address> element which contains a URI to the endpoint.

1317 Details for the DeliveryInfo element are defined in [regrep-rim-v4.0].

1318 7.4.1 Notification Option

1319 A client MAY specify a notificationOption attribute in DeliveryInfo element of a Subscription. The notifica-
1320 tionOption attribute specifies how the client wishes to be notified of events. This attribute controls whether
1321 the Event within a Notification contains complete RegistryObjectType instances or only ObjectRefType in-
1322 stances. It is defined in detail in ebRIM.

1323 7.4.2 Delivery to NotificationListener Web Service

1324 If the <wsa:Address> element has a rim:endpointType attribute value of “urn:oasis:names:tc:ebxml-re-
1325 grep:endPointType:soap”, then the server MUST use the specified address as the web service endpoint
1326 URL to deliver the Notification to. The target web service in this case MUST implement the Notification-
1327 Listener interface.

1328 7.4.3 Delivery to Email Address

1329 If the <wsa:Address> element has a rim:endpointType attribute value of “urn:oasis:names:tc:ebxml-re-
1330 grep:endPointType:rest”, then the server MUST use the specified address as the email address to deliver
1331 the Notification via email. This specification does not define how a server is configured to send Notifica-
1332 tions via email.

1333 7.4.4 Delivery to a NotificationListener Plugin

1334 If the <wsa:Address> element has a rim:endpointType attribute value of “urn:oasis:names:tc:ebxml-re-
1335 grep:endPointType:plugin”, then the server MUST use the specified address as a Notification plugin iden-
1336 tifier and deliver the Notification via local call to the plugin. This specification does not define how a server
1337 is configured for Notification plugins.

1338 7.4.4.1 Processing Email Notification Via XSLT

1339 A client MAY specify an XSLT style sheet within a DeliveryInfo element to process a Notification prior to it
1340 being delivered to an email address. The XSLT style sheet MAY be specified using a Slot in DeliveryInfo
1341 element where the Slot's name is “urn:oasis:names:tc:ebxml-regrep:rim:DeliveryInfo:emailNotification-
1342 Formatter” and the Slots value is the id of an ExtrinsicObject whose repository item is the XSLT. The Ex-
1343 trinsicObject and repository item MUST be submitted prior to or at the same time as the Subscription.

1344 7.5 NotificationListener Interface

1345 The NotificationListener interface allows a client to receive Notifications from the server for their Subscrip-
1346 tions. A client MUST implement the NotificationListener interface as an endpoint if they wish to receive
1347 Notifications via SOAP or REST. A server MUST implement a NotificationListener interface as an end-
1348 point if it supports the object replication feature as this endpoint will be used by remote servers to deliver
1349 Notification of changes to replicated objects.

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 67 of 95
1350 7.6 Notification Protocol
1351 A server sends a Notification to an endpoint using the Notification protocol supported by the onNotification
1352 operation of the NotificationListener interface.

1353 A server initiates the Notification protocol by sending a Notification message to the NotificationListener
1354 endpoint registered within the Subscription for which the Notification is being delivered.

Illustration 8: Notification Protocol

1355 The onNotification operation does not send a response back to the server.

1356 7.6.1 Notification

1357 The Notification message is sent by the server to a NotificationListener interface implemented by the cli-
1358 ent and delivers an event notification for a subscription. It is a one-way request pattern and produces no
1359 response. The syntax and semantics of the Notification message is described in detail in ebRIM.

1360 7.7 Pulling Notification on Demand

1361 A client MAY “pull” Notifications for a Subscription by invoking the GetNotification canonical query. A cli-
1362 ent MAY specify a startTime since which it wishes to include events within the pulled Notification. If client
1363 does not specify a startTime then all events since the last “push” delivery to that client's NotifyTo endpoint
1364 MUST be included in the Notification. If Subscription does not define any “push” delivery for that client's
1365 NotifyTo endpoint then a client MUST use startTime parameter to avoid getting the same events within
1366 the Notification returned by the GetNotification query.

1367 Pulling a Notification leaves the Notification intact on the server for any potential pushing of the Notifica-
1368 tion to endpoints defined in DeliveryInfo elements of the Subscription.

1369 7.8 Deleting a Subscription

1370 A client MAY terminate a Subscription with a server if it no longer wishes to be notified of events related
1371 to that Subscription. A client terminates a Subscription by deleting the corresponding Subscription object
1372 using the standard RemoveObjects protocol.

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 68 of 95
1373 8 Multi-Server Features
1374 This chapter describes features of ebXML RegRep that involve more than one ebXML RegRep server in-
1375 stances. These features include:

1376 ● Remote Object Reference – Allows references between objects residing in different servers

1377 ● Object Replication – Allows replication of objects residing in a remote server to a local server

1378 ● Federated Queries – Allows queries that execute against, and return results from multiple servers

1379 8.1 Remote Objects Reference

1380 A RegistryObject in one ebXML RegRep server MAY contain a reference to a RegistryObject in any other
1381 ebXML RegRep server that is compatible with ebXML RegRep specifications of a compatible version
1382 number as the source server. Remote object reference feature does not require the local and remote
1383 servers to be part of the same federation. Remote object references are described in detail in [regrep-rim-
1384 v4.0].

1385

1386 Illustration 9: Remote Object Reference

1387 8.2 Local Replication of Remote Objects

1388 RegistryObjects within a server MAY be replicated in another server. A replicated copy of a remote object
1389 is referred to as its replica. The remote object MAY be an original object or it MAY be a replica. A replica
1390 from an original is referred to as a first-generation replica. A replica of a replica is referred to as a second-
1391 generation replica (and so on).

1392 A server that replicates a remote object locally is referred to as the local server for the replication. The
1393 server that contains the remote object being replicated is referred to as the remote server for the replica-
1394 tion.

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 69 of 95
1395 Illustration 10: Local Replication of Remote Objects

1396 The following rules govern replication of remote objects:

1397 ● A server MUST match local replicas of remote objects in the same manner as local objects within
1398 the Query protocol.

1399 ● A client MUST NOT perform update operations via SubmitObjects and UpdateObjects operations
1400 on a local replica of a remote object.

1401 ● A server MUST return an InvalidRequestException fault message if a client attempts to update a
1402 replica via SubmitObjects and UpdateObjects operations.

1403 ● A server MUST delete a replica if a client uses RemoveObjects operation to remove the replica.

1404 ● Objects MAY be replicated from any server to any other server without any requirement that the
1405 registries belong to the same federation.

1406 8.2.1 Creating Local Replica and Keeping it Synchronized

1407 Replication feature relies upon the Subscription and Notification feature to keep replicas synchronized
1408 with changes to the remote object. A local replica of a remote objects is created as follows:

1409 ● A client submits a Subscription to the remote server on behalf of the local server.

1410 ○ The subscription is published like any other RegistryObjectType instance using the Submit
1411 Objects protocol with the LifecycleManager endpoint of the remote server.

1412 ○ This typically requires that the client is registered with the remote server and can authenticate
1413 with it.

1414 ● The Subscription defines a Selector query that matches one or more objects that need to be rep-
1415 licated from remote server to local server.

1416 ○ Selector query may match any number of objects using any selection criteria supported by
1417 the query.

1418 ● The Subscription specifies the address of a NotificationListener endpoint implemented by the
1419 local server where the remote server may send Notifications regarding the objects that need to be
1420 replicated.

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 70 of 95
1421 ● The local server uses the selector query for the subscription to PULL the initial copy of the remote
1422 object(s)

1423 ○ A server MUST NOT create a local replica for an object if a local object exists with the same
1424 id. In such case the server MUST return an ObjectExistsException fault message.

1425 ● Whenever the remote server send Notifications to the local server for the same Subscription, the
1426 local server synchronizes the local replica with the remote object.

1427 ○ A server MUST delete a local replica when its source object is deleted at the remote server.

1428 ○ A server MUST NOT delete a local object that is not a replica of a remote object if a notifica-
1429 tion arrives regarding the deletion of a remote object with the same id as the local object. In
1430 such case the server MUST return an InvalidRequestException fault message.

1431 A server MUST use standard QueryManager interface to read the state of a remote object. No prior regis-
1432 tration or contract is needed for a server to read the state of a remote object if that object is readable by
1433 anyone, as is the case with the default access control policy.

1434 Once the state of the remote object has been read, a server MAY use server specific means to create a
1435 local replica of the remote object.

1436 A server MUST set a Slot with name “urn:oasis:names:tc:ebxml-regrep:rim:RegistryObject:home” on a

1437 local replica. The value of the Slot MUST be a StringValueType that specifies the base URL of the home
1438 server for the remote object that is the source of the local replica. A server MUST NOT set a Slot with
1439 name “urn:oasis:names:tc:ebxml-regrep:rim:RegistryObject:home” on a local object within its home
1440 server. The presence of this slot distinguished a local replica of a remote object from a local object.

1441 8.2.2 Removing a Local Replica

1442 An authorized client can remove a local replica in the same manner as removal of local objects using the
1443 standard RemoveObjects protocol.

1444 8.2.3 Removing Subscription With Remote Server

1445 An authorized client can remove the Subscription at the remote server that was created on behalf of the
1446 local server using the standard RemoveObjects protocol with the remote server.

1447 8.3 Registry Federations

1448 A server federation is a set of ebXML RegRep servers that have voluntarily agreed to form a loosely
1449 coupled union. Such a federation may be based on common business interests or membership in a com-
1450 munity-of-interest. Registry federations enabled clients to query the content of their member servers using
1451 federated queries as if they are a single logical server.

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 71 of 95
1452 Illustration 11: Registry Federations

1453 8.3.1 Federation Configuration

1454 A deployment MAY configure a set of related ebXML RegRep servers as a Federation using the Registry
1455 and Federation classes defined in detail by [regrep-rim-v4.0]. Instances of these classes and the associ-
1456 ations between these instances describe a federation and its members.

1457 The Federation information model is described in [regrep-rim-v4.0].

1458 8.3.1.1 Creating a Federation

1459 The following rules govern how a federation is created:

1460 ● A Federation is created by submitting a Federation instance to a server using the SubmitObjects
1461 protocol

1462 ● The server where the Federation is created is referred to as the federation home

1463 ● A federation home MAY contain multiple Federation instances

1464 8.3.1.2 Joining a Federation

1465 The following rules govern how a server joins a federation:

1466 ● Each server SHOULD have exactly one local RegistryType instance. Each server MAY have mul-
1467 tiple remote RegistryType instances

1468 ● A server MAY join an existing federation by submitting an instance of an Association that associ-
1469 ates the Federation instance as sourceObject, to the Registry instance representing the server as
1470 targetObject, using a type of HasFederationMember. The home server for the Association and
1471 the Federation objects MUST be the same

1472 ● A Federation (child federation) MAY join an existing federation (parent federation) by submitting
1473 an instance of an Association that associates the Federation instance representing the parent
1474 federation as sourceObject, to the Federation instance representing the child federation as tar-
1475 getObject, using a type of HasFederationMember. The home server for the Association and the
1476 parent Federation objects MUST be the same

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 72 of 95
1477 8.3.1.3 Leaving a Federation
1478 The following rules govern how a server leaves a federation:

1479 ● A server or a federation MAY leave a federation at any time by removing the HasFederationMem-
1480 ber Association instance for its RegistryType or FederationType instance that links it with the par-
1481 ent FederationType instance. This is done using the standard RemoveObjects protocol.

1482 8.3.1.4 Dissolving a Federation

1483 The following rules govern how a federation is dissolved:

1484 ● A federation is dissolved using the standard RemoveObjects protocol against the Federation's
1485 home server and removing its FederationType instance

1486 ● The removal of a FederationType instance is governed by Access Control Policies like any other
1487 RegistryObject

1488 8.3.2 Local Vs. Federated Queries

1489 A client MAY query a federation as a single unified logical server. A QueryRequest sent by a client to a
1490 federation member MAY be local or federated depending upon the value of the federated attribute of the
1491 QueryRequest.

1492 8.3.2.1 Local Queries

1493 When the federated attribute of QueryRequest has the value of false (default) then the query is a local
1494 query.

1495 A local QueryRequest is only processed by the server that receives the request.

1496 8.3.2.2 Federated Queries

1497 When the federated attribute of QueryRequest has the value of true then the query is a federated query.

1498 A server MUST route a federated query received by it to all servers that are represented by RegistryType
1499 instances in the membership tree of the federation(s) that is the target of the federated query on a best at-
1500 tempt basis.

1501 If an exception is encountered while dispatching a query to a federation member the server MUST return
1502 a QueryResponse as follows:

1503 ● The status of the QueryResponse MUST reference the canonical “PartialSuccess” Classification-
1504 Node within the canonical ResponseStatusType ClassificationScheme

1505 ● The QueryResponse MUST have a set of Exception sub-elements of type rs:RegistryException-
1506 Type, one for each exception encountered while dispatching a query to a remote server

1507 When a server routes a federated query to a federation member server then it MUST set the federated at-
1508 tribute value of the QueryRequest to false and the federation attribute value to null to avoid infinite loops.

1509 A federated query operates on data that is distributed across all the members of the target federation.

1510 When a client submits a federated query to a server and no federations exist in the server, then the server
1511 MUST treat it as a local query.

1512 The following rules apply to the treatment of iterative queries when the query is federated:

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 73 of 95
1513 ● A server MUST return a result set whose size is less than or equal to the maxResults parameter
1514 depending upon whether enough results are available within the scope of servers in the federa-
1515 tion, starting at startIndex.

1516 ● A server MUST return the same result in a deterministic manner for the same federated
1517 QueryRequest if no changes have been made in between the request to the federation member
1518 servers and their collective state.

1519 ● A server MAY choose any implementation specific algorithm to select results from its federation
1520 members for each iteration of an iterative query as long as the algorithm is deterministic and re-
1521 peatably produces the same results for the same set of federation members and their collective
1522 state. For example a server MAY use a sequential algorithm that gets as many results from each
1523 of its server sequentially until it satisfies the maxResults parameter or until there are no more res-
1524 ults. Alternatively, a server MAY use a parallel algorithm that balances the amount of data re-
1525 trieved from each of its federation members.

1526 8.3.3 Local Replication of Federation Configuration

1527 A federation member is required to locally cache the federation configuration metadata in the Federation
1528 home server for each federation that it is a member of. A server SHOULD use the replication feature for
1529 locally caching the Federation configuration.

1530 The federation member MUST keep the cached federation configuration synchronized with the original
1531 object in the Federation home.

1532 8.3.4 Time Synchronization Between Federation Members

1533 Federation members are not required to synchronize their system clocks with each other. However, each
1534 Federation member SHOULD keep its clock synchronized with an atomic clock server within the latency
1535 described by the replicationSyncLatency attribute of the Federation.

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 74 of 95
1536 9 Governance Features
1537 This chapter specifies how a server supports governance of RegistryObjects.

1538 Governance is defined as the enforcement of business processes and policies defined by a Community of
1539 Practice, that guide, direct, and control how its members collaborate to achieve its business goals.

1540 Within this specification, governance is defined as the enforcement of collaborative business processes
1541 and policies defined by a Community of Practice to manage the end-to-end life cycle of RegistryObjects
1542 within the server. Such collaborative business processes will be referred to as “governance collabora-
1543 tions”.

1544 The remainder of this chapter specifies:

1545 ● Scope of governance collaborations

1546 ● How governance collaborations are represented,

1547 ● How representations of governance collaborations are assigned to RegistryObjects, and

1548 ● How a server uses the representation of governance collaborations assigned to a RegistryOb-
1549 jects to govern them

1550

1551 9.1 Representing a Governance Collaboration

1552 This specification makes use of BPMN 2.0 2 [BPMN2] to represent business collaborations that govern Re-
1553 gistryObjects as follows:

1554 ● Uses BPMN 2.0 diagram notation to pictorially represent business collaborations

1555 ● Uses BPMN 2.0 XML format to declaratively represent business collaborations in a machine pro-
1556 cessable syntax

1557 A governance collaboration consists of one or more participants where each participant's activities within
1558 the collaboration is described by a separate BPMN process and the interaction between the participants'
1559 processes is described by a single BPMN collaboration.

1560 Detailed specification of how to describe governance collaborations in BPMN 2.0 XML format and how a
1561 server executes them in a BPMN process engine are provided later in this chapter.

1562 Illustration 12 below provides an example of the Default Governance Collaboration represented by a
1563 BPMN 2.0 diagram notation. The Default Governance Collaboration is provided as a standard gov-
1564 ernance collaboration readily available for use in any server. It is described in detail later in this chapter.

2
At the time of this writing BPMN 2.0 is not final yet. This specification uses the BPMN 2.0 Beta 2 spe-
cification as a reference at this time since BPMN 2.0 is not final yet.
regrep-core-rs-v4.0-os 25 January 2012
Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 75 of 95
regrep-core-rs-v4.0-os 25 January 2012
Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 76 of 95
1566 9.1.1 Content of Governance Collaboration BPMN Files
1567 The collective content of the Governance Collaboration BPMN files, whether organized as a set of related
1568 modular files or a single monolithic file, MUST meet the following requirements:

1569 ● There MUST be exactly one collaboration element

1570 ● The collaboration element MUST have at least one participant element

1571 ● At least once participant element MUST have id value of “registryPartcipant” and represents the
1572 RegRep server as a participant within the governance collaboration

1573 ● There MUST be a processRef element for the “registryPartcipant”

1574 ● There MUST be a process element for each processRef attribute in each participant element

1575 ● The process element for other participants than the “registryPartcipant” participant MAY conform
1576 to “Descriptive Conformance Sub-Class ”3 or “Analytic Conformance Sub-Class ”4 in [BPMN2] and
1577 need not be executed within a BPMN process engine

1578 ● The process element for the “registryPartcipant” participant's process MUST conform to “Com-
1579 mon Executable Conformance Sub-Class”5 in [BPMN2] and MUST be executed by the server in a
1580 BPMN process engine

1581 ● The process elements SHOULD use tasks that conform to canonical task patterns defined later in
1582 this specification whenever possible

1583

1584 9.2 Scope of Governance Collaborations

1585 A governance collaboration may govern a single RegistryObject or it may govern a set of related Registry-
1586 Objects packaged together within a RegistryPackage as a single unit of governance. In either case, the
1587 target object of the governance collaboration is referred to as the governed object.

1588 9.2.1 Packaging Related Objects as a Governance Unit

1589 A client MUST publish a set of related RegistryObjects that are to be governed by the server as a single
1590 unit as follows:

1591 ● The objects MUST be immediate members of the same RegistryPackage

1592 ● The RegistryPackage MUST have a canonical slot with name “urn:oasis:names:tc:ebxml-
1593 regrep:rim:RegistryPackage:packageType”

1594 ● The value of the packageType slot MUST be a unique identifier for the type of package of which
1595 the group of related objects are an instance

1596 A server MUST treat RegistryPackages with a canonical slot with name “urn:oasis:names:tc:ebxml-re-
1597 grep:rim:RegistryPackage:packageType” as the governed object.

3
This is also referred to as a “Layer 1”, representation layer or presentation layer
4
This is also referred to as a “Layer 2” or analytical layer
5
This is also referred to as a “Layer 3” or executable layer
regrep-core-rs-v4.0-os 25 January 2012
Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 77 of 95
1598 9.3 Assigning a Governance Collaboration
1599 A governance collaboration as represented by a BPMN2 XML file is not directly assigned to a RegistryOb-
1600 ject. Instead it is assigned to a RegistryPackage and is implicitly applicable to RegistryObjects that are
1601 members of the RegistryPackage.

1602 Governance collaboration MAY be assigned to a specific RegistryPackage using a “GovernedBy” Associ-
1603 ation as follows:

1604 ● The type attribute value of Association MUST reference the canonical “GovernedBy” Classifica-
1605 tionNode within the canonical AssociationType ClassificationScheme whose id is
1606 “urn:oasis:names:tc:ebxml-regrep:AssociationType:GovernedBy”

1607 ● The targetObject attribute value of Association MUST reference an ExtrinsicObject with object-
1608 Type “urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:ExtrinsicObject:XML:BPMN2”

1609 ● The repository item for the ExtrinsicObject MUST be an XML document conforming to the
1610 BPMN2 model XML Schema. If the modular approach to BPMN description is used then this file
1611 MUST be the collaboration BPMN file. The file MUST import or contain the BPMN process for the
1612 “Registry” participant

1613 ● The sourceObject attribute value of Association MUST reference the RegistryPackage instance to
1614 which the governance collaboration is being assigned

1615 ● The RegistryPackage MUST NOT have a canonical slot with name “urn:oasis:names:tc:ebxml-re-
1616 grep:rim:RegistryPackage:packageType”

1617 9.4 Determining Applicable Governance Collaboration

1618 For any given RegistryObject, a server MUST use the following algorithm to determine the applicable gov-
1619 ernance collaboration (if any):

1620 1. Check if objects is an immediate member of a RegistryPackage that has a canonical slot with
1621 name “urn:oasis:names:tc:ebxml-regrep:rim:RegistryPackage:packageType”.

1622 a) If it is so, then the object is not governed directly and instead its parent RegistryObjects is the
1623 governed object

1624 b) Otherwise, proceed to next step

1625 2. Check if there is a governance collaboration assigned to a RegistryPackage ancestor using the
1626 canonical “HasGovernance” Association as follows:

1627 a) Do a breadth-first traversal of the tree consisting of all RegistryPackage ancestors of the ob-
1628 ject and for each RegistryPackage see if it has a governance collaboration assigned to it

1629 b) Stop when you find the first such governance collaboration

1630 c) If a governance collaboration is found then use it as applicable governance collaboration

1631 3. If no RegistryPackage-specific governance collaboration is found then the object is not governed
1632 by any governance collaboration

1633

1634 9.5 Determining the Registry Process in a Governance Collaboration

1635 For any given governance collaboration, a server MUST use the following algorithm to determine the spe-
1636 cial Registry process:

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 78 of 95
1637 1. Find the participant element within the collaboration whose id is the canonical “registryParticipant”

1638 2. Find the processRef attribute of the “registryParticipant” and use the referenced process as the
1639 Registry process

1640 9.6 Starting the Registry Process for a Governance Collaboration

1641 The BPMN process for the “registryParticipant” within a governance collaboration is the only process in
1642 the collaboration that is required to be executed by the server within a BPMN process engine. This sec-
1643 tion specifies when and how a server starts this process.

1644 9.6.1 Starting Registry Process By WorkflowAction

1645 A server MAY start the Registry process for a governance collaboration in response to the publishing of a
1646 WorkflowAction object. This is specified in detail in 10.8.1.1 Server Processing of WorkflowAction.

1647 9.7 Incoming messageFlows to Registry Process

1648 Within a governance collaboration, a server MUST support incoming messageFlows to the Registry pro-
1649 cess from other processes in the collaboration that meet the following requirements:

1650 ● The sourceRef attribute of the messageFlow references a task that conforms to the
1651 SendWorkflowAction task template described later in this chapter

1652 ● The targetRef attribute of the messageFlow references a task that conforms to the
1653 ReceiveWorkflowAction task template described later in this chapter

1654 ● The messageRef attribute of the messageFlow is defined and references a message whose item-
1655 Definition has attribute structureRef="rim:WorkflowActionType"

1656

1657 A server MAY support other types of incoming messages.

1658 9.8 Outgoing messageFlows from Registry Process

1659 A Registry process communicates with non-Registry processes by sending them notification messages.
1660 These messages may be an email message to an email endpoint for a person or a rim:NotificationType
1661 message to a service endpoint. Details are provided in the specification for the SendNotification task
1662 pattern.

1663 A server MAY support other types of outgoing messages.

1664 9.9 Canonical Task Patterns

1665 This section specifies a set of canonical task patterns that may be used within participant processes in a
1666 governance collaboration. Some of these task patterns can only be used within the Registry process while
1667 some may only be used in the non-Registry processes of a governance collaboration.

1668 The following table provides a brief summary each of the canonical tasks defined by this specification.
1669 Subsequent sections specify these tasks in more detail.

1670
Task Pattern Task Type Used Description
In

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 79 of 95
 SendWorkflow sendTask Non-Registry Sends a WorkflowAction message to the Registry process
Action Process

ReceiveWorkflow receiveTask Registry Pro- Waits until a WorkflowAction message is received from a non-
Action cess Registry process

SendNotification scriptTask Registry Pro- Sends a Notification message to a non-Registry process

cess

ReceiveNotification receiveTask Non-Registry Receives a Notification message from the Registry process
Process

SetStatus scriptTask Registry Pro- Sets the status of the specified RegistryObject
cess

Validate serviceTask Any Process Validates a RegistryObject

Catalog serviceTask Any Process Catalogs a RegistryObject

1671

1672 9.9.1 SendWorkflowAction Task Pattern

1673 This canonical task pattern is used by a sendTask to represent the performing of a process-specific action
1674 upon the governed object. This task pattern is the primary means for a non-Registry process to send a
1675 message to the Registry process to trigger the Registry process forward.

1676 Task Inputs: The task has the following inputs as defined by dataInput elements in its ioSpecification:

1677 ● A dataInput that has an itemSubjectRef attribute that references an itemDefinition element whose
1678 structureRef attribute value is “rim:WorkflowActionType”

1679 Task Outputs:The task has no outputs.

1680 Task Actors: This task SHOULD be performed by a role other than Registry role to indicate that some
1681 external action (e.g. “approval”) has been performed on the targetObject specified by the WorkflowAction.

1682 Description: To perform this task the actor submits a WorkflowAction to the server using the standard
1683 SubmitObjects protocol. The name of the task SHOULD reflect the action being performed by the task
1684 (e.g. name='SendWorkflowAction(RequestForReview)'. The WorkflowAction MUST specify:

1685 ● An action attribute identifying the action performed

1686 ● A targetObject attribute identifying the object that is the target of the action. Typically, this is the
1687 governed object

1688 9.9.1.1 Server Processing of WorkflowAction

1689 Upon publishing of a WorkflowAction a server MUST process it as shown in the following pseudo-code
1690 and explained further below:

1691
WorkflowActionType workflowAction = ...;
Collaboration collaboration =
getApplicableGovernanceCollaboration(workflowAction.getTargetObject());

if (collaboration != null) {
Process registryProcess = collaboration.getRegistryProcess();
if (registryProcess != null) {

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 80 of 95
 if (!registryProcess.isActive()) {
registryProcess.start();
}
registryProcess.deliverMessage(workflowAction);
}
}

1692

1693 1. Determine and get the applicable Governance Collaboration (as defined in 10.3 Determining
1694 Applicable Governance Collaboration)

1695 2. Determine and get the applicable Registry process for the collaboration (as defined in 10.4
1696 Determining the Registry Process in a Governance Collaboration)

1697 3. If the Registry process has not yet been started then start it within the BPMN process engine

1698 4. Deliver the WorkflowAction message to the Registry process where presumably a receiveTask
1699 based on the ReceiveWorkflowAction task pattern is waiting for it

1700

1701 9.9.2 ReceiveWorkflowAction Task Pattern

1702 This canonical task pattern is used by a receiveTask that waits for a process-specific action to be per-
1703 formed upon the governed object. This task pattern is the primary means for the Registry process to re-
1704 ceive a message from a non-Registry process to trigger the Registry process forward.

1705 Task Inputs: The task has the following inputs as defined by dataInput elements in its ioSpecification:

1706 ● A dataInput that has an itemSubjectRef attribute that references an itemDefinition element whose
1707 structureRef attribute value is “rim:WorkflowActionType”

1708 Task Outputs:The task has no outputs.

1709 Task Actors: This task MUST be performed by the Registry role to wait until some external action (e.g.
1710 “approval”) has been performed on the targetObject specified by the WorkflowAction.

1711 Description: This task waits until the server delivers a WorkflowAction message to the Registry process.
1712 The name of the task SHOULD reflect the action being performed (e.g.
1713 name='ReceiveWorkflowAction(RequestForReview)'. The task is typically followed by sequenceFlow ele-
1714 ments that have a conditionExpression that predicate on the value of the action attribute of the Work-
1715 flowAction.

1716 9.9.3 SendNotification Task Pattern

1717 This canonical task pattern is used by a scriptTask to send a Notification message regarding the gov-
1718 erned object to the roles and email addresses specified for the task. This task pattern is the primary
1719 means for the Registry process to send a message to a non-Registry process to trigger the non-Registry
1720 process forward.

1721 Task Inputs: None

1722 Task Outputs: None

1723 Task Actors: This task MUST be performed by the Registry role to keep governance roles for the gov-
1724 erned object informed of important changes (e.g. status attribute changes) during the course of the life
1725 cycle of the governed object.

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 81 of 95
1726 Description: To perform this task the actor uses the sendNotification canonical XPATH extension
1727 function defined later in this chapter. The name of the task SHOULD reflect the nature of the notification
1728 being sent by the task (e.g. name='SendNotification(Accept)'.

1729 9.9.4 ReceiveNotification Task Pattern

1730 This canonical task pattern is used by a receiveTask that waits for a Notification message to be delivered.
1731 This task pattern is the primary means for a non-Registry process to receive a message from the Registry
1732 process to trigger the non-Registry process forward.

1733 Task Inputs: The task has the following inputs as defined by dataInput elements in its ioSpecification:

1734 ● A dataInput that has an itemSubjectRef attribute that references an itemDefinition element whose
1735 structureRef attribute value is “rim:NotificationType”

1736 Task Outputs:The task has no outputs.

1737 Task Actors: This task MUST be performed by a non-Registry role

1738 Description: This task waits until the server delivers a Notification message. The name of the task
1739 SHOULD reflect the nature of the notification being received by the task (e.g.
1740 name='ReceiveNotification(Accept)'.

1741 9.9.5 SetStatus Task

1742 This canonical task pattern is used by a scripTask that updates the status of the specified object to a spe-
1743 cified status value.

1744 Task Inputs: None

1745 Task Outputs: None

1746 Task Actors: This task MUST be performed by the Registry role to reflect changes in life cycle status
1747 during the course of the life cycle of the governed object.

1748 Description: To perform this task the actor uses the setStatus canonical XPATH extension function
1749 defined later in this chapter. The name of the task SHOULD reflect the status being set by the task (e.g.
1750 name='SendStatus(Approved)'.

1751 9.9.6 Validate Task

1752 This canonical task represents the validation of the governed object.

1753 Task Inputs: The task has no explicit inputs.

1754 Task Outputs:The task has no outputs.

1755 Task Actors: This task SHOULD be performed by the Registry role in response to the creation or updat-
1756 ing of the governed object.

1757 Description: To perform this task the actor validates the governed object using the standard ValidateOb-
1758 jects protocol. The name of the task SHOULD be 'Validate' or an equivalent native language translation.

1759 9.9.7 Catalog Task

1760 This canonical task represents the cataloging of the governed object.

1761 Task Inputs: The task has no explicit inputs.

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 82 of 95
1762 Task Outputs: The task has no outputs.

1763 Task Actors: This task SHOULD be performed by the Registry role in response to the creation or updat-
1764 ing of the governed object.

1765 Description: To perform this task the actor catalogs the governed object using the standard CatalogOb-
1766 jects protocol. The name of the task SHOULD be 'Catalog' or an equivalent native language translation.

1767 9.10 XPATH Extension Functions

1768 The following table specifies XPATH extension functions that MUST be supported by the BPMN process
1769 engine used by the server. The function signatures are described using the same conventions as used in
1770 section 1.4 of [XPATHFUNC].

1771 These functions MAY be used within XPATH expressions in a BPMN file wherever a tExpression type is
1772 supported by the BPMN schema.

1773 ● The namespace URI for these functions MUST be "urn:oasis:names:tc:ebxml-regrep:xsd:rs:4.0"

1774 ● The namespace prefix SHOULD be “rs”

1775
XPATH Extension Function Description

rs:generateId() as xs:string Returns a newly generated unique id for a RegistryOb-

ject. This SHOULD be a URN in the urn:uuid namespace

rs:getRegistryObject(id as xs:string) as element() Returns the RegistryObject element for the RegistryOb-
ject that matches the specified id after retrieving it from
the server. This is typically used to get the governed ob-
ject.

rs:setStatus(targetObject as xs:string, status as Sets the status of the object matching targetObject with
xs:string) as none the specified status. Used by the SetStatus task pattern.
This function returns no value.

rs:sendNotification(toRoles as xs:string*, toEmails as Send a notification message using an optional subject to

xs:string*, subject as xs:string?, message as xs:string) as specified roles and email addresses. If toRoles is spe-
none cified then the server MUST be able to resolve each role
to a target person or service instances and determine a
delivery endpoint for the target. The message SHOULD
be specified as a CDATA if it contains any special char-
acters used by XML. This function returns no value.
Used by the SendNotification task pattern.

1776

1777 In addition to the functions described in table above, all canonical query functions supported by the server
1778 MUST also be supported by the server as XPATH functions.

1779 9.11 Default Governance Collaboration

1780 This section defines a canonical governance collaboration called the “Default Governance Collaboration”.
1781 The Default Governance Collaboration is defined by this specification to provide a standard governance
1782 process that can be supported by all implementations and may be assigned to specific RegistryPackages.

1783 The Default Governance Collaboration is represented by a canonical ExtrinsicObjectType instance with id
1784 “urn:oasis:names:tc:ebxml-regrep:collaboration:DefaultGovernanceCollaboration”.

1785 A BPMN diagram for the Default Governance Collaboration has been provided in Illustration 12 earlier.
regrep-core-rs-v4.0-os 25 January 2012
Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 83 of 95
1786 The Default Governance Collaboration is summarized as follows:

1787 ● The submitter requests review and approval of the governed object using SendWorkflowAction
1788 canonical task pattern with action “RequestForReview”

1789 ● The server receives the “RequestForReview” WorkflowAction and notifies the reviewer roles of
1790 the request for review using Notify canonical task pattern

1791 ● A reviewer accepts the request for review using SendWorkflowAction canonical task with Work-
1792 flowAction “Accept”

1793 ● The server notifies submitter roles that the governed object is under review using the using Notify
1794 canonical task

1795 ● The reviewer approves or rejects the governed objects using SendWorkflowAction canonical task
1796 and actions “Approve” or “Reject”

1797 ● The server notifies the submitter of the outcome of the review using the using Notify canonical
1798 task

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 84 of 95
1799 10 Security Features
1800 This chapter describes the security features of ebXML RegRep. A glossary of security terms can be refer-
1801 enced from [RFC 2828]. This specification incorporates by reference the following specifications:

1802 ● [WSS-CORE] WS-Security Core Specification 1.1, February 2006.

1803 http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-
1804 SOAPMessageSecurity.pdf

1805 ● [WSS-UNT] WS-Security Username Token Profile 1.1, February 2006.

1806 http://www.oasis-open.org/committees/download.php/16782/wss-v1.1-spec-os-
1807 UsernameTokenProfile.pdf

1808 ● [WSS-X509] WS-Security X.509 Token Profile 1.1, February 2006.

1809 http://www.oasis-open.org/committees/download.php/16785/wss-v1.1-spec-os-
1810 x509TokenProfile.pdf

1811 ● [WSS-SAML] WS-Security SAML Token profile 1.1, February 2006.

1812 http://www.oasis-open.org/committees/download.php/16768/wss-v1.1-spec-os-
1813 SAMLTokenProfile.pdf

1814 ● [WSS-KRB] WS-Security Kerberos Token Profile 1.1, February 2006.

1815 http://www.oasis-
1816 open.org/committees/download.php/16788/wss-v1.1-spec-os-KerberosTokenProfile.pdf
1817

1818 10.1 Message Integrity

1819 A server MUST provide for message integrity to ensure that client requests and server responses are not
1820 tampered with during transmission (man-in-the-middle attack).

1821 10.1.1 Transport Layer Security

1822 A server SHOULD support HTTP/S protocol for all ebXML RegRep protocols defined by this specification.
1823 HTTP/S protocol support SHOULD allow for both SSL and TLS as transport protocols.

1824 10.1.2 SOAP Message Security

1825 A server MUST support soap message security for all ebXML RegRep protocols defined by this specifica-
1826 tion when those protocols are bound to SOAP.

1827 SOAP message security MUST conform to [WSS-CORE].

1828 The [WSS-CORE] has several profiles for supporting various types of security tokens in a standard man-
1829 ner. A server MUST support at least one of the following types of security token:

1830 ● Username tokens as specified by [WSS-UNT]

1831 ● X509 Certificate tokens as specified by [WSS-X509T]

1832 ● SAML tokens as defined by [WSS-SAMLT]

1833 ● Kerberos tokens as specified by [WSS-KRBT]

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 85 of 95
1834 10.2 Message Confidentiality
1835 A server SHOULD support encryption of protocol messages as defined by section 9 of [WSS-CORE] as a
1836 mechanism to support confidentiality of all ebXML RegRep protocols defined by this specification when
1837 those protocols are bound to SOAP.

1838 10.3 User Registration and Identity Management

1839 A server MUST provide a user registration mechanism to register and manage authorized users of the
1840 server. A server MUST also provide an identity management mechanism to register and manage the se-
1841 curity tokens associated with registered users. This specification does not define how a server provides
1842 user registration and identity management mechanisms.

1843 10.4 Authentication

1844 A server MUST support authentication of the client requests based on the security tokens provided by the
1845 client and supported by the server. This specification does not specify the mechanism used by a server to
1846 authenticate client requests. Server implementations MAY use any means to provide authentication cap-
1847 ability.

1848 10.5 Authorization and Access Control

1849 A server MUST control access by client to resources it manages based upon:

1850 ● The access control policy associated with each resource.

1851 ● The action the client is performing

1852 ● The identity associated with the client as well as any roles assigned to that identity

1853 A server MUST provide an access control and authorization mechanism based upon chapter titled “Ac-
1854 cess Control Information Model” in [regrep-rim-v4.0]. This model defines a default access control policy
1855 that MUST be supported by the server. In addition it also defines a binding to [XACML] that allows fine-
1856 grained access control policies to be defined.

1857 10.6 Audit Trail

1858 A server MUST keep a journal or audit trail of all operations that result in changing the state of its re-
1859 sources. This provides a basic form of non-repudiation where a client cannot repudiate that it performed
1860 actions that are logged in the Audit Trail.

1861 A server MUST create an audit trail for each request that affected the state of server resources. A server
1862 MUST create this audit trail using AuditableEventType instances as define by the chapter title “Event In-
1863 formation Model” of [regrep-rim-v4.0].

1864 Details of how a server maintains an Audit Trail of client requests is described in the chapter title “Event
1865 Information Model” of [regrep-rim-v4.0].

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 86 of 95
1866 11 Native Language Support (NLS)
1867 This chapter describes the Native Languages Support (NLS) features of ebXML RegRep.

1868 11.1 Terminology

1869 The following terms are used in NLS.
NLS Term Description

Coded Character Set (CCS) CCS is a mapping from a set of abstract characters to a
set of integers. [RFC 2130]. Examples of CCS are ISO-
10646, US-ASCII, ISO-8859-1, and so on.

Character Encoding Scheme (CES) CES is a mapping from a CCS (or several) to a set of
octets. [RFC 2130]. Examples of CES are ISO-2022,
UTF-8.

Character Set (charset) • Charset is a set of rules for mapping from a se-
quence of octets to a sequence of characters.
[RFC 2277],[RFC 2278]. Examples of character
set are ISO-2022-JP, EUC-KR.
• A list of registered character sets can be found
at [IANA].
1870

1871 11.2 NLS and Registry Protocol Messages

1872 For the accurate processing of data in both client and server, it is essential for the recipient of a protocol
1873 message to know the character set being used by it.

1874 A client SHOULD specify charset parameter in MIME header when they specify text/xml as Content-Type.

1875 The following is an example of specifying the character set in the MIME header.

Content-Type: text/xml; charset=ISO-2022-JP

1876

1877 If a server receives a protocol message with the charset parameter omitted then it MUST use the default
1878 charset value of "us-ascii" as defined in [RFC 3023].

1879 Also, when an application/xml entity is used, the charset parameter is optional, and client and server
1880 MUST follow the requirements in Section 4.3.3 of [REC-XML] which directly address this contingency.

1881 If another Content-Type is used, then usage of charset MUST follow [RFC 3023].

1882 11.3 NLS Support in RegistryObjects

1883 The information model XML Schema [regrep-xsd-v4.0] defines the rim:InternationalStringType for defining
1884 elements that contains a locale sensitive string value.

1885

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 87 of 95
 <complexType name="InternationalStringType">
<sequence>
<element name="LocalizedString" type="tns:LocalizedStringType"
minOccurs="0" maxOccurs="unbounded" />
</sequence>
</complexType>

1886

1887 An InternationalStringType may contain zero or more rim:LocalizedString elements within it where each
1888 LocalizedString contain a string value is a specified local language.

1889
<complexType name="LocalizedStringType">
<attribute ref="xml:lang" use="optional" default="en-US"/>
<attribute name="value" type="tns:FreeFormText" use="required"/>
</complexType>

1890

1891 Examples of such elements are the “Name” and “Description” elements of the RegistryObject class
1892 defined by [regrep-rim-v4.0].

1893 An element InternationalString is capable of supporting multiple locales within its collection of Localized-
1894 Strings.

1895 The schema allows a single RegistryObject instance to include values for any NLS sensitive element in
1896 multiple locales.

1897 The following example illustrates how a single RegistryObject can contain NLS sensitive <rim:Name> and
1898 “<rim:Description> elements with their value specified in multiple locales. Note that the <rim:Name> and
1899 <rim:Description> use the rim:InternationalStringType as their type.
<rim:RegistryObject xsi:type="rim:ExtrinsicObjectType"...>
<rim:Name>
<rim:LocalizedString xml:lang="en-US" value="customACP1.xml"/>
<rim:LocalizedString xml:lang="fi-FI" value="customACP1.xml"/>
<rim:LocalizedString xml:lang="pt-BR" value="customACP1.xml"/>
</rim:Name>
<rim:Description>
<rim:LocalizedString xml:lang="en-US" value="A sample custom ACP"/>
<rim:LocalizedString xml:lang="fi-FI" value="Esimerkki custom ACP"/>
<rim:LocalizedString xml:lang="pt-BR" value="Exemplo de ACP customizado"/>
</rim:Description>
</rim:RegistryObjectType>
1900

1901 Since locale information is specified at the sub-element level there is no language associated with a spe-
1902 cific RegistryObject instance.

1903 11.3.1 Language of a LocalizedString

1904 The language MAY be specified in xml:lang attribute (Section 2.12 [REC-XML]).

1905 11.3.2 Character Set of RegistryObject

1906 The character set used by a RegistryObjects is defined by the charset attribute within the Content-Type
1907 mime header for the XML document containing the RegistryObject as shown below:
1908
1909 Content-Type: text/xml; charset="UTF-8"
regrep-core-rs-v4.0-os 25 January 2012
Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 88 of 95
1910
1911

1912 Clients SHOULD specify UTF-8 or UTF-16 as the value of the charset attribute of LocalizedStrings for
1913 maximum interoperability. A server MUST preserve the charset of a repository item as it is originally spe-
1914 cified when it is submitted to the server.

1915 11.4 NLS and Repository Items

1916 While a single instance of an ExtrinsicObject is capable of supporting multiple locales, it is always associ-
1917 ated with a single repository item. The repository item MAY be in a single locale or MAY be in multiple
1918 locales. This specification does not specify any NLS requirements for repository items.

1919 11.4.1 Character Set of Repository Items

1920 When a submitter submits a repository item, they MAY specify the character set used by the repository
1921 item using the MIME Content-Type mime header for the mime multipart containing the repository item as
1922 shown below:
1923
1924 Content-Type: text/xml; charset="UTF-8"

1925

1926 A server MUST preserve the charset of a repository item as it is originally specified when it is submitted to
1927 the server.

1928 11.4.2 Language of Repository Items

1929 This specification currently does not provide for a mechanism to specify the language of a Repository-
1930 Item.

1931 This document currently specifies only the method of sending the information of character set and lan-
1932 guage, and how it is stored in a server. However, the language information MAY be used as one of the
1933 query criteria, such as retrieving only DTD written in French. Furthermore, a language negotiation proced-
1934 ure, like client asking a preferred language for messages from server, could be functionality for a future
1935 revision of this document.

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 89 of 95
1936 12 REST Binding
1937 This chapter specifies a minimal REST binding for the QueryManager interface. This binding will be re-
1938 ferred to as Core REST binding. Additional, more detailed REST bindings such as binding for ATOM,
1939 ATOM Pub, Open Search etc. will be defined by separate specifications. These additional specification
1940 will also provide a RESTFul interface to the LifecycleManager interface.

1941 12.1 Canonical URL

1942 The canonical URL is an HTTP GET URL that MAY be used to reference or access RegistryObjectType
1943 instance in a RESTful manner. The canonical URL provides a simple universally supported means to ac-
1944 cess the object via HTTP GET. A server MUST provide access to its RegistryObjectType instances and
1945 repository items via canonical URLs as defined in sections below. Access to such resources MUST be
1946 controlled by the applicable access control policies associated with these resources as defined by ebRIM
1947 under the chapter titled Access Control Information Model.

1948 12.1.1 Canonical URL for RegistryObjects

1949 The canonical URL for RegistryObjectType has the following pattern:
//The {id} parameter specifies the id of a RegistryObject
GET /rest/registryObjects/{id}

1950

1951 The following are examples of valid canonical URLs for RegistryObjectType instances. Note that for read-
1952 ability we do not encode special characters in the id attribute value.

1953
//Get RegistryObject with id: urn:acme:pictures:danyal.jpg
GET http://acme.com/myregistry/rest/registryObjects/urn:acme:pictures:danyal.jpg

//Get RegistryObject id: http://www.acme.com/pictures/danyal.jpg

GET http://acme.com/myregistry/rest/registryObjects/http://www.acme.com/pictures/danyal.jpg

1954

1955 12.1.2 Canonical URL for Repository Items

1956 The canonical URL for repository items has the following pattern:
//The {id} parameter specifies the id of a RegistryObject for repository item
GET /rest/repositoryItems/{id}

1957

1958 The following are examples of valid canonical URLs for RegistryObjectType instances. Note that for read-
1959 ability we do not encode special characters in the id attribute value.

1960
//Get repository item associated with
//ExtrinsicObject with id: urn:acme:pictures:danyal.jpg
GET http://acme.com/myregistry/rest/repositoryItems/urn:acme:pictures:danyal.jpg

//Get repository item associated with

regrep-core-rs-v4.0-os 25 January 2012
Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 90 of 95
 //ExtrinsicObject with id: http://www.acme.com/pictures/danyal.jpg
GET http://acme.com/myregistry/rest/repositoryItems/http://www.acme.com/pictures/danyal.jpg

1961

1962 12.2 Query Protocol REST Binding

1963 A server MUST implement a REST Binding for the Query Protocol of the Query Manager interface as
1964 specified in this section. This binding allows a client to invoke any parameterized query supported by the
1965 server in a RESTful manner.

1966 The URL pattern or template for the parameterized query invocation is as follows:
1967
#Template URL for parameterized query invocation
<server base url>/rest/search?queryId={the query id}(&{<param-name>=<param-
value>})*

1968

1969 The following example shows the use of the FindObjectsByIdAndType canonical query using the REST
1970 binding.
#Get RegistryObject with id: urn:acme:pictures:danyal.jpg
GET http://acme.com/myregistry/rest/search?queryId=urn:oasis:names:tc:ebxml-
regrep:query:FindObjectById&id=urn:acme:pictures:danyal.jpg
1971

1972 12.2.1 Parameter queryId

1973 The queryId parameter MUST specify the id of a parameterized stored query while zero or more addi-
1974 tional parameters MAY provide parameter name and value pairs for parameters supported by the query. If
1975 the queryId is unspecified then it implicitly specifies the value “urn:oasis:names:tc:ebxml-
1976 regrep:query:FindObjectById” as the default queryId.

1977 12.2.2 Query Specific Parameters

1978 A parameterized query MAY define any number of query-specific parameters. A client MAY specify val-
1979 ues for these parameters MAY as additional options to the URL. For example, the
1980 id=urn:acme:pictures:danyal.jpg part in example URL above supplies a value for the id query-specific
1981 parameter defined by the FindObjectsByIdAndType query.

1982 In addition to query-specific parameters, every query invocation URL MUST also support one or more ca-
1983 nonical query parameters. These are described in subsequent sections.

1984 12.2.3 Canonical Query Parameter: depth

1985 This canonical query parameter represents the same named attribute and associated semantics as
1986 defined for Query Request.
1987
#Example: Find objects matching specifies keywords and also return
#related objects reachable by up to 10 levels of references
/rest/search/?queryId=urn:oasis:names:tc:ebxml-
regrep:query:FindObjectByKeywords&keywords=automobile;japan&depth=10

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 91 of 95
1988 12.2.4 Canonical Query Parameter: format
1989 This canonical query parameter represents the same named attribute and associated semantics as
1990 defined for Query Request.
1991
#Example: Find 10 resources by keywords using en-us language and ebRS format
/rest/search/?queryId=urn:oasis:names:tc:ebxml-
regrep:query:FindObjectByKeywords&keywords=automobile;japan&lang=en-
us&format=application/x-ebrs+xml
1992

1993 12.2.5 Canonical Query Parameter: federated

1994 This canonical query parameter represents the same named attribute and associated semantics as
1995 defined for Query Request.
1996
#Example: Perform a federated query across members of all configured
federations
/rest/search/?queryId=urn:oasis:names:tc:ebxml-
regrep:query:FindObjectByKeywords&keywords=automobile;japan&federated=true
1997

1998 12.2.6 Canonical Query Parameter: federation

1999 This canonical query parameter represents the same named attribute and associated semantics as
2000 defined for Query Request.
2001
#Example: Perform a federated query across members of specified federation
/rest/search/?queryId=urn:oasis:names:tc:ebxml-
regrep:query:FindObjectByKeywords&keywords=automobile;japan&federated=true&fed
eration=urn:acme:federation:acme-partners
2002

2003 12.2.7 Canonical Query Parameter: matchOlderVersions

2004 This canonical query parameter represents the same named attribute and associated semantics as
2005 defined for Query Request.
2006
#Example: Find objects matching specified name and include older versions of
matched objects if they match
/rest/search/?queryId=urn:oasis:names:tc:ebxml-
regrep:query:BasicQuery&name=TestRegister1&matchOlderVersionsOnQuery=true

2007 12.2.8 Canonical Query Parameter: startIndex

2008 This canonical query parameter represents the same named attribute and associated semantics as
2009 defined for Query Request.
2010
#Example: Find 10 resources by keywords starting at index 30

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 92 of 95
 /rest/search/?queryId=urn:oasis:names:tc:ebxml-
regrep:query:FindObjectByKeywords&keywords=automobile;japan&maxResults=10&star
tIndex=30
2011

2012 12.2.9 Canonical Query Parameter: lang

2013 This canonical query parameter represents the same named attribute and associated semantics as
2014 defined for Query Request.
2015
#Example: Find resources by keywords using en-us language
/rest/search/?queryId=urn:oasis:names:tc:ebxml-
regrep:query:FindObjectByKeywords&keywords=automobile;japan&lang=en-us
2016

2017 12.2.10 Canonical Query Parameter: maxResults

2018 This canonical query parameter represents the same named attribute and associated semantics as
2019 defined for Query Request.
2020
#Example: Find 10 resources by keywords
/rest/search/?queryId=urn:oasis:names:tc:ebxml-
regrep:query:FindObjectByKeywords&keywords=automobile;japan&maxResults=10

2021 12.2.11 Use of Functions in Query Parameters

2022 Query functions may be used in query parameters as defined in Query Function. The only caveat is that
2023 the special characters such as the special sequences “#@” and “@#”, special characters “(“, “)” etc.
2024 MUST be specified in their URL encoded representation as defined by RFC 3986 and RFC 3629.

2025 For example a query parameter “#@'@#rs:currentTime#@'@#” would evaluate to the current time as a
2026 quoted timestamp string in ISO 8601 format such as “#@'@#2010-08-05T17:14:18.866#@'@#”. Such a
2027 query parameter in REST interface would have to be URL encoded to be as shown in the following ex-
2028 ample:
http://localhost:8080/omar-server/rest/search?
queryId=urn:ogc:specification:regrep:profile:ISO19139:query:DatasetDiscoveryQu
ery&title=%23%40%%2740%23ebrs:currentTime%28%29%23%40%%2740%23

2029 12.2.12 Query Response

2030 The response document returned by the Query Protocol REST binding MUST be a QueryResponse docu-
2031 ment. If the format parameter value is unspecified or if it is specified as “application/x-ebrs+xml” then the
2032 response document must have query:QueryResponse element as its root element.

2033

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 93 of 95
2034 13 SOAP Binding
2035 This chapter specifies the requirements for SOAP Binding that a regrep server or client must adhere to.
2036 The normative definition of service endpoint, protocols and their SOAP binding is contained within the
2037 WSDL 1.1 definitions defined by [regrep-wsdl-v4.0]. A WSDL 2.0 definition is also available in [re-
2038 grep-wsdl-v4.0].

2039 The following additional requirements are defined by this specification for the SOAP binding:

2040 ● A server MUST use WS-Addressing SOAP Headers when sending a Notification message to a
2041 SOAP endpoint as defined here.

2042 13.1 WS-Addressing SOAP Headers

2043 The following rules apply to a server when sending a Notification message to a SOAP endpoint for the
2044 NotificationListener.

2045 ● Use of WS-Addressing SOAP headers MUST conform to [WSA-SOAP].

2046 ● A server MUST set the content of the wsa:MessageID element to a unique id. A server SHOULD
2047 generate a universally unique id value that conform to the format of a URN that specifies a DCE
2048 128 bit UUID as specified in [UUID] (e.g. urn:uuid:a2345678-1234-1234-123456789012).

2049 ● A server MUST set the wsa:ReplyTo SOAP header element

2050 ○ The wsa:Address elements content MUST be set to the base URL for the server.

2051 ● A server MUST set the content of the wsa:To element to the SOAP endpoint URL where the mes-
2052 sage is being sent to.

2053 ● A server MUST set the content of the wsa:Action element to the value of the soapAction attribute
2054 of the soap:operation element for the operation defined for the SOAP binding for the interface's
2055 WSDL.

2056 The following example shows a SOAP message containing a Notification intended for a Notification-
2057 Listener SOAP endpoint.

2058
<env:Envelope>
<env:Header>
<wsa:MessageID>
urn:uuid:3e79348f-d696-4fac-a015-a4bae0bf83c5
</wsa:MessageID>
<wsa:ReplyTo>
<wsa:Address>http://www.acme.com/regrep</wsa:Address>
</wsa:ReplyTo>
<wsa:To>http://www.client.com/notificationListener</wsa:To>
<wsa:Action>urn:oasis:names:tc:ebxml-
regrep:wsdl:NotificationListener:bindings:4.0:NotificationListener:onNotificat
ion</wsa:Action>
</env:Header>
<env:Body>
<rim:Notification .../>
</env:Body>
</env:Envelope>

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 94 of 95
2059 Appendix A. Protocol Exceptions
2060 This appendix defines the standard exception that may be returned by various protocols defined in this
2061 specification. These exceptions MUST be returned as SOAP fault messages in the SOAP binding for the
2062 protocols. Implementations SHOULD provide relevant details regarding the exception within the Detail
2063 element of the fault.
XSD Element Name Description

AuthenticationException Generated by server when a client sends a request with authentication creden-
tials and the authentication fails for any reason.

AuthorizationException Generated by server when a client sends a request to the server for which it is
not authorized.

CatalogingException Generated by server when a problem is encountered during the processing of

a CatalogObjectsRequest.

InvalidRequestException Generated by server when a client sends a request that is syntactically or se-
mantically invalid.

ObjectExistsException Generated by the server when a SubmitObjectsRequest attempts to create an

object with the same id as an existing object and the mode is “CreateOnly”.

ObjectNotFoundException Generated by the server when a QueryRequest expects an object but it is not
found in server.

QueryException Generated by server when when a problem is encountered during the pro-
cessing of a QueryRequest.

QuotaExceededException
Generated by server when a a request exceeds a server specific quota
for the client.

ReferencesExistException
Generated by server when a RemoveObjectRequest attempts to re-
move a RegistryObject while references to it still exist.

TimeoutException
Generated by server when a the processing of a request exceeds a
server specific timeout period.

UnresolvedReferenceException Generated by the server when a request references an object that cannot be
resolved within the request or to an existing object in the server.

UnsupportedCapabilityException Generated by server when when a request attempts to use an optional feature
or capability that the server does not support.

ValidationException Generated by server when a problem is encountered during the processing of

a ValidateObjectsRequest.

2064

regrep-core-rs-v4.0-os 25 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 95 of 95