OASIS/ebXML Registry Services Specification v3.0
1
OASIS/ebXML Registry Services Specification v2.4
–Committee Working Draft
OASIS/ebXML Registry Technical Committee
July 2017
Copyright © OASIS, 2002. All Rights Reserved
July 2017
OASIS/ebXML Registry Services Specification v3.0
2
July 2017
This page intentionally left blank.
Copyright © OASIS, 2002. All Rights Reserved
Page 2 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
3
1 Status of this Document
4
This document is an OASIS Registry Technical Committee Working Draft - September 2002.
5
Distribution of this document is unlimited.
6
The document formatting is based on the Internet Society’s Standard RFC format.
7
8
9
10
11
12
13
14
15
This version:
http://www.oasis-open.org/committees/regrep/documents/2.5/specs/ebrs-2.4.pdf
Latest Technical Committee Approved version:
http://www.oasis-open.org/committees/regrep/documents/2.1/specs/ebrs.pdf
Latest OASIS Approved Standard:
http://www.oasis-open.org/committees/regrep/documents/2.0/specs/ebrs.pdf
Copyright © OASIS, 2002. All Rights Reserved
Page 3 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
16
2 OASIS/ebXML Registry Technical Committee
17
18
This is an OASIS/ebXML Registry Technical Committee draft document. The following
persons are members of the OASIS/ebXML Registry Technical Committee:
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
Zachary Alexander, Individual Member
John Bekisz, Software AG, Inc.
Kathryn Breininger, Boeing
Lisa Carnahan, NIST
Joseph M. Chiusano, Booz Allen Hamilton
Suresh Damodaran, Sterling Commerce
Fred Federlein, Sun Microsystems
Sally Fuger, Individual Member
Peter Kacandes, Adobe Systems Incorporated
Michael Kass, NIST
Kyu-Chul Lee, Individual Member
Paul Macias, LMI
Matthew MacKenzie, Individual Member
Komal Mangtani, BEA Systems
Monica Martin, Sun Microsystems
Farrukh Najmi, Sun Microsystems
Sanjay Patil, IONA
Nikola Stojanovic, Individual Member
Uday Subarayan, Sun Microsystems
Scott Zimmerman, Storagepoint
39
Contributors
40
41
The following persons contributed to the content of this document, but were not a voting member
of the OASIS/ebXML Registry Technical Committee.
42
43
44
45
46
47
Anne Fischer, Individual
Len Gallagher, NIST
Duane Nickull, XML Global
John Silva, Philips Medical
Sekhar Vajjhala, Sun Microsystems
48
Copyright © OASIS, 2002. All Rights Reserved
Page 4 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
49
Table of Contents
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
1
Status of this Document ........................................................................................................ 3
2
OASIS/ebXML Registry Technical Committee ................................................................. 4
Table of Contents .......................................................................................................................... 5
Table of Figures........................................................................................................................... 11
Table of Tables ............................................................................................................................ 13
3
Introduction ......................................................................................................................... 14
3.1 Summary of Contents of Document ................................................................14
3.2 General Conventions ........................................................................................14
3.3 Audience ..........................................................................................................14
4
Design Objectives ................................................................................................................ 15
4.1 Goals ................................................................................................................15
4.2 Caveats and Assumptions ................................................................................15
5
System Overview ................................................................................................................. 16
5.1 What The ebXML Registry Does ....................................................................16
5.2 How The ebXML Registry Works ...................................................................16
5.2.1 Schema Documents Are Submitted .....................................................16
5.2.2 Business Process Documents Are Submitted ......................................16
5.2.3 Seller’s Collaboration Protocol Profile Is Submitted...........................16
5.2.4 Buyer Discovers The Seller .................................................................16
5.2.5 CPA Is Established ..............................................................................17
5.3 Registry Users ..................................................................................................17
5.4 Where the Registry Services May Be Implemented ........................................18
5.5 Implementation Conformance .........................................................................18
5.5.1 Conformance as an ebXML Registry ..................................................18
5.5.2 Conformance as an ebXML Registry Client ........................................19
6
ebXML Registry Architecture ........................................................................................... 20
6.1 Registry Service Described ..............................................................................20
6.2 Abstract Registry Service ................................................................................20
6.2.1 LifeCycleManager Interface ................................................................21
6.2.2 QueryManager Interface ......................................................................21
6.3 Concrete Registry Services ..............................................................................22
6.4 SOAP Binding .................................................................................................23
6.4.1 WSDL Terminology Primer ................................................................23
6.4.2 Concrete Binding for SOAP ................................................................23
6.5 ebXML Message Service Binding ...................................................................24
6.5.1 Service and Action Elements ...............................................................24
6.5.2 Synchronous and Asynchronous Responses ........................................24
6.5.3 ebXML Registry Collaboration Profiles and Agreements ...................25
6.6 HTTP Binding ..................................................................................................25
6.6.1 Standard URI Parameters .....................................................................25
6.6.2 QueryManager HTTP Interface ...........................................................26
6.6.3 LifeCycleManager HTTP Interface .....................................................28
6.6.4 Security Considerations .......................................................................29
6.6.5 Exception Handling .............................................................................29
6.7 Registry Clients ................................................................................................29
Copyright © OASIS, 2002. All Rights Reserved
Page 5 of 188
OASIS/ebXML Registry Services Specification v3.0
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
7
8
July 2017
6.7.1 Registry Client Described ....................................................................29
6.7.2 Registry Communication Bootstrapping..............................................30
6.7.3 RegistryClient Interface .......................................................................31
6.7.4 Registry Response ................................................................................32
6.8 Interoperability Requirements .........................................................................32
6.8.1 Client Interoperability ..........................................................................32
6.9 Registry Requests and Responses ....................................................................32
6.9.1 RegistryRequestType ...........................................................................32
6.9.2 RegistryResponseType ........................................................................33
6.9.3 RegistryResponse .................................................................................34
6.9.4 RegistryErrorList .................................................................................34
6.9.5 RegistryError........................................................................................35
6.9.6 ErrorType .............................................................................................35
Lifecycle Management Service .......................................................................................... 37
7.1 Lifecycle of a RegistryObject ..........................................................................37
7.2 RegistryObject Attributes ................................................................................37
7.3 The Submit Objects Protocol ...........................................................................38
7.3.1 SubmitObjectsRequest .........................................................................38
7.3.2 RegistryResponse .................................................................................39
7.3.3 Universally Unique ID Generation ......................................................39
7.3.4 ID Attribute And Object References ....................................................40
7.3.5 Audit Trail ............................................................................................40
7.3.6 Sample SubmitObjectsRequest ............................................................40
7.4 The Update Objects Protocol ...........................................................................44
7.4.1 UpdateObjectsRequest .........................................................................44
7.4.2 Audit Trail ............................................................................................45
7.5 The Add Slots Protocol ....................................................................................45
7.5.1 AddSlotsRequest ..................................................................................46
7.6 The Remove Slots Protocol .............................................................................47
7.6.1 RemoveSlotsRequest ...........................................................................47
7.7 The Approve Objects Protocol.........................................................................48
7.7.1 ApproveObjectsRequest ......................................................................49
7.7.2 Audit Trail ............................................................................................50
7.8 The Deprecate Objects Protocol ......................................................................50
7.8.1 DeprecateObjectsRequest ....................................................................50
7.8.2 Audit Trail ............................................................................................51
7.9 The Undeprecate Objects Protocol ..................................................................51
7.9.1 UndeprecateObjectsRequest ................................................................52
7.9.2 Audit Trail ............................................................................................53
7.10 The Remove Objects Protocol .........................................................................53
7.10.1 RemoveObjectsRequest .......................................................................53
Query Management Service ............................................................................................... 56
8.1 Ad Hoc Query Request/Response ....................................................................56
8.1.1 AdhocQueryRequest ............................................................................57
8.1.2 AdhocQueryResponse..........................................................................58
8.1.3 ReponseOption .....................................................................................58
8.1.4 Iterative Query Support........................................................................60
8.2 Filter Query Support ........................................................................................60
Copyright © OASIS, 2002. All Rights Reserved
Page 6 of 188
OASIS/ebXML Registry Services Specification v3.0
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
9
July 2017
8.2.1 FilterQuery ...........................................................................................62
8.2.2 RegistryObjectQuery ...........................................................................64
8.2.3 RegistryEntryQuery .............................................................................76
8.2.4 AssociationQuery.................................................................................79
8.2.5 AuditableEventQuery ..........................................................................82
8.2.6 ClassificationQuery..............................................................................85
8.2.7 ClassificationNodeQuery .....................................................................86
8.2.8 ClassificationSchemeQuery .................................................................91
8.2.9 RegistryPackageQuery .........................................................................93
8.2.10 ExtrinsicObjectQuery ..........................................................................95
8.2.11 OrganizationQuery...............................................................................97
8.2.12 ServiceQuery......................................................................................100
8.2.13 FederationQuery ................................................................................103
8.2.14 RegistryQuery ....................................................................................104
8.2.15 SubscriptionQuery .............................................................................105
8.2.16 UserQuery ..........................................................................................106
8.2.17 Registry Filters ...................................................................................108
8.2.18 XML Clause Constraint Representation ............................................112
8.3 SQL Query Support .......................................................................................117
8.3.1 SQL Query Syntax Binding To [ebRIM]...........................................117
8.3.2 Semantic Constraints On Query Syntax ............................................119
8.3.3 SQL Query Results ............................................................................119
8.3.4 Simple Metadata Based Queries ........................................................119
8.3.5 RegistryObject Queries ......................................................................120
8.3.6 RegistryEntry Queries ........................................................................120
8.3.7 Classification Queries ........................................................................120
8.3.8 Association Queries ...........................................................................121
8.3.9 Package Queries .................................................................................122
8.3.10 ExternalLink Queries .........................................................................122
8.3.11 Audit Trail Queries ............................................................................123
8.3.12 Object Export Queries........................................................................123
8.4 Content Retrieval ...........................................................................................123
8.4.1 GetContentRequest ............................................................................124
8.4.2 GetContentResponse ..........................................................................125
8.4.3 Identification Of Content Payloads ....................................................125
8.4.4 GetContentResponse Message Structure ...........................................125
Content Management Services ........................................................................................ 128
9.1 Content Validation .........................................................................................128
9.1.1 Content Validation: Use Cases ..........................................................128
9.2 Content Cataloging ........................................................................................129
9.2.1 Content-based Discovery: Use Cases ................................................129
9.3 Abstract Content Management Service .........................................................130
9.3.1 Inline Invocation Model .....................................................................130
9.3.2 De-coupled Invocation Model ...........................................................131
9.4 Content Management Service Protocol .........................................................132
9.4.1 ContentManagementServiceRequestType .........................................132
9.4.2 ContentManagementServiceResponseType ......................................134
9.5 Publishing / Configuration of a Content Management Service .....................134
Copyright © OASIS, 2002. All Rights Reserved
Page 7 of 188
OASIS/ebXML Registry Services Specification v3.0
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
9.6
9.7
9.8
9.9
9.10
10
10.1
10.2
10.3
10.4
10.5
10.6
10.7
11
11.1
11.2
July 2017
9.5.1 Multiple Content Management Services and Invocation Control Files136
Invocation of a Content Management Service ...............................................136
9.6.1 Resolution Algorithm For Service and Invocation Control File ........136
9.6.2 Audit Trail and Cataloged Content ....................................................137
9.6.3 Referential Integrity ...........................................................................137
9.6.4 Error Handling ...................................................................................137
Validate Content Protocol ..............................................................................137
9.7.1 ValidateContentRequest ....................................................................138
9.7.2 ValidateContentResponse ..................................................................139
Catalog Content Protocol ...............................................................................140
9.8.1 CatalogContentRequest......................................................................140
9.8.2 CatalogContentResponse ...................................................................141
Illustrative Example: Default XML Cataloging Service ...............................142
Default XML Content Cataloging Service ....................................................143
9.10.1 Publishing of Default XML Content Cataloging Service ..................144
Event Notification Service ...................................................................................... 145
Use Cases .......................................................................................................145
10.1.1 CPP Has Changed ..............................................................................145
10.1.2 New Service is Offered ......................................................................145
10.1.3 Monitor Download of Content ...........................................................145
10.1.4 Monitor Price Changes ......................................................................145
10.1.5 Keep Replicas Consistent With Source Object ..................................145
Registry Events ..............................................................................................146
Subscribing to Events ....................................................................................146
10.3.1 Event Selection ..................................................................................147
10.3.2 Notification Action ............................................................................147
10.3.3 Subscription Authorization ................................................................147
10.3.4 Subscription Quotas ...........................................................................147
10.3.5 Subscription Expiration .....................................................................147
10.3.6 Subscription Rejection .......................................................................148
Unsubscribing from Events............................................................................148
Notification of Events ....................................................................................148
Retrieval of Events .........................................................................................149
10.6.1 GetNotificationsRequest ....................................................................149
10.6.2 NotificationType ................................................................................149
10.6.3 ObjectRefsNotification ......................................................................150
10.6.4 ObjectsNotification ............................................................................150
Purging of Events ...........................................................................................151
Cooperating Registries Support ............................................................................ 152
Cooperating Registries Use Cases .................................................................152
11.1.1 Inter-registry Object References ........................................................152
11.1.2 Federated Queries ..............................................................................152
11.1.3 Local Caching of Data from Another Registry ..................................152
11.1.4 Object Relocation...............................................................................153
Registry Federations ......................................................................................153
11.2.1 Federation Metadata...........................................................................153
11.2.2 Local Vs. Federated Queries ..............................................................154
11.2.3 Federated Lifecycle Management Operations ...................................155
Copyright © OASIS, 2002. All Rights Reserved
Page 8 of 188
OASIS/ebXML Registry Services Specification v3.0
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
July 2017
11.2.4 Federations and Local Caching of Remote Data ...............................155
11.2.5 Caching of Federation Metadata ........................................................155
11.2.6 Time Synchronization Between Registry Peers .................................155
11.2.7 Federations and Security ....................................................................156
11.2.8 Federation Lifecycle Management Protocols ....................................156
11.3 Object Replication .........................................................................................157
11.3.1 Use Cases for Object Replication ......................................................157
11.3.2 Queries And Replicas ........................................................................158
11.3.3 Lifecycle Operations And Replicas ...................................................158
11.3.4 Object Replication and Federated Registries .....................................158
11.3.5 Creating a Local Replica ....................................................................158
11.3.6 Transactional Replication ..................................................................158
11.3.7 Keeping Replicas Current ..................................................................159
11.3.8 Write Operations on Local Replica....................................................159
11.3.9 Tracking Location of a Replica..........................................................159
11.3.10 Remote Object References to a Replica.........................................159
11.3.11 Removing a Local Replica .............................................................159
11.4 Object Relocation Protocol ............................................................................159
11.4.1 RelocateObjectsRequest ....................................................................162
11.4.2 AcceptObjectsRequest .......................................................................163
11.4.3 Object Relocation and Remote ObjectRefs .......................................163
11.4.4 Notification of Object Relocation To ownerAtDestination ...............164
11.4.5 Notification of Object Commit To sourceRegistry ............................164
11.4.6 Object Relocation and Timeouts ........................................................165
12
Registry Security ..................................................................................................... 166
12.1 Security Concerns ..........................................................................................166
12.2 Integrity of Registry Content .........................................................................166
12.2.1 Message Payload Signature ...............................................................166
12.2.2 Payload Signature Requirements .......................................................167
12.3 Authentication ................................................................................................168
12.3.1 Message Header Signature .................................................................169
12.4 Key Distribution and KeyInfo Element .........................................................170
12.5 Confidentiality ...............................................................................................171
12.5.1 On-the-wire Message Confidentiality ................................................171
12.5.2 Confidentiality of Registry Content ...................................................171
12.6 Access Control and Authorization .................................................................171
12.6.1 Actors / Role Mapping .......................................................................171
Appendix A
Web Service Architecture .......................................................................... 173
A.1 Registry Service Abstract Specification ........................................................173
A.2 Registry Service SOAP Binding ....................................................................173
Appendix B
ebXML Registry Schema Definitions ........................................................ 174
B.1 RIM Schema ..................................................................................................174
B.2 Registry Services Interface Base Schema ......................................................174
B.3 QueryManager Service Schema .....................................................................174
B.4 LifecycleManager Service Schema................................................................174
B.5 Examples of Instance Documents ..................................................................174
Appendix C
Interpretation of UML Diagrams .............................................................. 175
Copyright © OASIS, 2002. All Rights Reserved
Page 9 of 188
OASIS/ebXML Registry Services Specification v3.0
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
July 2017
C.1 UML Class Diagram ......................................................................................175
C.2 UML Sequence Diagram ...............................................................................175
Appendix D
SQL Query................................................................................................... 176
D.1 SQL Query Syntax Specification ...................................................................176
D.2 Non-Normative BNF for Query Syntax Grammar ........................................176
D.3 Relational Schema For SQL Queries .............................................................177
Appendix E
Security Implementation Guideline .......................................................... 178
E.1 Security Concerns ..........................................................................................178
E.2 Authentication ................................................................................................179
E.3 Authorization .................................................................................................179
E.4 Registry Bootstrap .........................................................................................179
E.5 Content Submission – Client Responsibility .................................................179
E.6 Content Submission – Registry Responsibility .............................................179
E.7 Content Remove/Deprecate – Client Responsibility .....................................180
E.8 Content Remove/Deprecate – Registry Responsibility..................................180
E.9 Using ds:KeyInfo Field ..................................................................................180
Appendix F
Native Language Support (NLS) ............................................................... 182
F.1 Definitions......................................................................................................182
F.1.1 Coded Character Set (CCS): ..............................................................182
F.1.2 Character Encoding Scheme (CES): ..................................................182
F.1.3 Character Set (charset):......................................................................182
F.2 NLS And Request / Response Messages .......................................................182
F.3 NLS And Storing of RegistryObject ..............................................................182
F.3.1 Character Set of LocalizedString .......................................................183
F.3.2 Language Information of LocalizedString .........................................183
F.4 NLS And Storing of Repository Items...........................................................183
F.4.1 Character Set of Repository Items .....................................................183
F.4.2 Language information of repository item ..........................................183
13
References ................................................................................................................ 184
14
Disclaimer ................................................................................................................ 186
15
Contact Information ............................................................................................... 187
16
Copyright Statement ............................................................................................... 188
Copyright © OASIS, 2002. All Rights Reserved
Page 10 of 188
OASIS/ebXML Registry Services Specification v3.0
319
Table of Figures
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
July 2017
Figure 1: Actor Relationships ................................................................................................ 18
Figure 2: ebXML Registry Service Architecture ................................................................... 20
Figure 3: The Abstract ebXML Registry Service .................................................................. 20
Figure 4: A Concrete ebXML Registry Service ..................................................................... 22
Figure 5: Registry Architecture Supports Flexible Topologies ............................................. 30
Figure 6: RegistryRequestType Syntax.................................................................................. 32
Figure 7: RegistryResponseType Syntax ............................................................................... 33
Figure 8: RegistryErrorList Syntax ........................................................................................ 34
Figure 9: RegistryError Syntax .............................................................................................. 35
Figure 10: Lifecycle of a RegistryObject ............................................................................... 37
Figure 11: Submit Objects Sequence Diagram ...................................................................... 38
Figure 12: SubmitObjectsRequest Syntax.............................................................................. 38
Figure 13: Update Objects Sequence Diagram ...................................................................... 44
Figure 14: UpdateObjectsRequest Syntax.............................................................................. 44
Figure 15: Add Slots Sequence Diagram ............................................................................... 46
Figure 16: AddSlotsRequest Syntax ...................................................................................... 46
Figure 17: Remove Slots Sequence Diagram ......................................................................... 47
Figure 18: RemoveSlotsRequest Syntax ................................................................................ 48
Figure 19: Approve Objects Sequence Diagram .................................................................... 49
Figure 20: ApproveObjectsRequest Syntax ........................................................................... 49
Figure 21: Deprecate Objects Sequence Diagram.................................................................. 50
Figure 22: DeprecateObjectsRequest Syntax ......................................................................... 51
Figure 23: Undeprecate Objects Sequence Diagram.............................................................. 52
Figure 24: UndeprecateObjectsRequest Syntax ..................................................................... 52
Figure 25: Remove Objects Sequence Diagram .................................................................... 53
Figure 26: RemoveObjectsRequest Syntax ............................................................................ 54
Figure 27: Submit Ad Hoc Query Sequence Diagram ........................................................... 56
Figure 28: AdhocQueryRequest Syntax ................................................................................. 57
Figure 29: AdhocQueryResponse Syntax .............................................................................. 58
Figure 30: ResponseOption Syntax ........................................................................................ 59
Figure 31: Example ebRIM Binding ...................................................................................... 61
Figure 32: ebRIM Binding for RegistryObjectQuery ............................................................ 64
Figure 33: ebRIM Binding for RegistryEntryQuery .............................................................. 77
Figure 34: ebRIM Binding for AssociationQuery ................................................................. 80
Figure 35: ebRIM Binding for AuditableEventQuery ........................................................... 82
Figure 36: ebRIM Binding for ClassificationQuery .............................................................. 85
Figure 37: ebRIM Binding for ClassificationNodeQuery ...................................................... 87
Figure 38: ebRIM Binding for ClassificationSchemeQuery .................................................. 92
Figure 39: ebRIM Binding for RegistryPackageQuery ......................................................... 93
Figure 40: ebRIM Binding for ExtrinsicObjectQuery ........................................................... 95
Copyright © OASIS, 2002. All Rights Reserved
Page 11 of 188
OASIS/ebXML Registry Services Specification v3.0
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
July 2017
Figure 41: ebRIM Binding for OrganizationQuery ............................................................... 97
Figure 42: ebRIM Binding for ServiceQuery ...................................................................... 101
Figure 43: ebRIM Binding for FederationQuery ................................................................. 103
Figure 44: ebRIM Binding for RegistryQuery ..................................................................... 104
Figure 45: ebRIM Binding for SubscriptionQuery .............................................................. 105
Figure 46: ebRIM Binding for OrganizationQuery Add PersonName under User and line up
106
Figure 47: The Clause Structure........................................................................................... 112
Figure 48: Content Retrieval Sequence Diagram ................................................................. 124
Figure 49: GetContentRequest Syntax ................................................................................. 124
Figure 50: GetContentResponse Syntax .............................................................................. 125
Figure 51: Content Validation Service ................................................................................. 128
Figure 52: Content Cataloging Service ................................................................................ 129
Figure 53: Content Management Service: Inline Invocation Model ................................... 131
Figure 54: Content Management Service: De-coupled Invocation Model .......................... 132
Figure 55: ContentManagementServiceRequestType Syntax.............................................. 133
Figure 56: Content ContentManagementServiceResponseType Syntax ............................. 134
Figure 57: Cataloging Service Configuration ...................................................................... 135
Figure 58: Validate Content Protocol................................................................................... 138
Figure 59: ValidateContentRequest Syntax ......................................................................... 138
Figure 60: ValidateContentResponse Syntax ....................................................................... 139
Figure 61: Catalog Content Protocol .................................................................................... 140
Figure 62: CatalogContentRequest Syntax .......................................................................... 141
Figure 63: CatalogContentResponse Syntax ........................................................................ 142
Figure 64: Example of CPP cataloging using Default XML Cataloging Service ................ 143
Figure 65: GetNotificationsRequest Syntax ......................................................................... 149
Figure 66: NotificationType Syntax ..................................................................................... 150
Figure 67: ObjectRefsNotification Syntax ........................................................................... 150
Figure 68: ObjectsNotification Syntax ................................................................................. 151
Figure 69: Inter-registry Object References ......................................................................... 152
Figure 70: Registry Federations ........................................................................................... 153
Figure 71: Federation Metadata Example ............................................................................ 154
Figure 72: Object Replication .............................................................................................. 157
Figure 73: Object Relocation ...................................................................................................... 160
Figure 74: Relocate Objects Protocol................................................................................... 161
Figure 75: RelocateObjectsRequest XML Schema .............................................................. 162
Figure 76: AcceptObjectsRequest Syntax ............................................................................ 163
Copyright © OASIS, 2002. All Rights Reserved
Page 12 of 188
OASIS/ebXML Registry Services Specification v3.0
398
Table of Tables
399
400
401
402
403
404
405
406
407
408
July 2017
Table 1: Registry Users .......................................................................................................... 17
Table 2: LifeCycle Manager Summary .................................................................................. 21
Table 3: Query Manager ........................................................................................................ 21
Table 4: Standard URI Parameters ......................................................................................... 25
Table 5: QueryManager HTTP Interface ............................................................................... 26
Table 6: LifeCycleManager HTTP Interface ......................................................................... 28
Table 7: RegistryClient Summary .......................................................................................... 31
Table 8: Path Filter Expressions for Use Cases ..................................................................... 90
Table 9: Default Actor to Role Mappings ............................................................................ 172
Copyright © OASIS, 2002. All Rights Reserved
Page 13 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
409
3 Introduction
410
3.1 Summary of Contents of Document
411
412
This document defines the interface to the ebXML Registry Services as well as interaction
protocols, message definitions and XML schema.
413
414
415
A separate document, ebXML Registry Information Model [ebRIM], provides information on
the types of metadata that are stored in the Registry as well as the relationships among the
various metadata classes.
416
3.2 General Conventions
417
The following conventions are used throughout this document:
418
419
UML diagrams are used as a way to concisely describe concepts. They are not intended to
convey any specific Implementation or methodology requirements.
420
421
422
The term “repository item” is used to refer to an object (e.g., an XML document or a DTD) that
resides in a repository for storage and safekeeping. Each repository item is described by a
RegistryObject instance. The RegistryObject catalogs the RepositoryItem with metadata.
423
424
425
426
427
The term "ExtrinsicObject" is used to refer to an object that provides metadata about a repository
item.
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD
NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be
interpreted as described in RFC 2119 [Bra97].
428
429
Software practitioners MAY use this document in combination with other ebXML specification
documents when creating ebXML compliant software.
430
3.3 Audience
431
432
433
The target audience for this specification is the community of software developers who are:
Implementers of ebXML Registry Services
Implementers of ebXML Registry Clients
434
Related Documents
435
436
437
438
439
The following specifications provide some background and related information to the reader:
a) ebXML Registry Information Model [ebRIM]
b) ebXML Message Service Specification [ebMS]
c) ebXML Business Process Specification Schema [ebBPSS]
d) ebXML Collaboration-Protocol Profile and Agreement Specification [ebCPP]
Copyright © OASIS, 2002. All Rights Reserved
Page 14 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
440
4 Design Objectives
441
4.1 Goals
442
443
444
445
446
The goals of this version of the specification are to:
Communicate functionality of Registry services to software developers
Specify the interface for Registry clients and the Registry
Provide a basis for future support of more complete ebXML Registry requirements
Be compatible with other ebXML specifications
447
4.2 Caveats and Assumptions
448
449
450
This version of the Registry Services Specification is the second in a series of phased
deliverables. Later versions of the document will include additional capability as deemed
appropriate by the OASIS/ebXML Registry Technical Committee. It is assumed that:
451
452
453
454
455
456
457
Interoperability requirements dictate that at least one of the normative interfaces as referenced in
this specification must be supported.
1. All access to the Registry content is exposed via the interfaces defined for the Registry
Services.
2. The Registry makes use of a Repository for storing and retrieving persistent information
required by the Registry Services. This is an implementation detail that will not be
discussed further in this specification.
Copyright © OASIS, 2002. All Rights Reserved
Page 15 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
458
5 System Overview
459
5.1 What The ebXML Registry Does
460
461
462
463
The ebXML Registry provides a set of services that enable sharing of information between
interested parties for the purpose of enabling business process integration between such parties
based on the ebXML specifications. The shared information is maintained as objects in a
repository and managed by the ebXML Registry Services defined in this document.
464
5.2 How The ebXML Registry Works
465
466
467
This section describes at a high level some use cases illustrating how Registry clients may make
use of Registry Services to conduct B2B exchanges. It is meant to be illustrative and not
prescriptive.
468
469
470
471
472
473
The following scenario provides a high level textual example of those use cases in terms of
interaction between Registry clients and the Registry. It is not a complete listing of the use cases
that could be envisioned. It assumes for purposes of example, a buyer and a seller who wish to
conduct B2B exchanges using the RosettaNet PIP3A4 Purchase Order business protocol. It is
assumed that both buyer and seller use the same Registry service provided by a third party. Note
that the architecture supports other possibilities (e.g. each party uses its own private Registry).
474
5.2.1 Schema Documents Are Submitted
475
476
477
A third party such as an industry consortium or standards group submits the necessary schema
documents required by the RosettaNet PIP3A4 Purchase Order business protocol with the
Registry using the LifeCycleManager service of the Registry described in Section 7.3.
478
5.2.2 Business Process Documents Are Submitted
479
480
481
A third party, such as an industry consortium or standards group, submits the necessary business
process documents required by the RosettaNet PIP3A4 Purchase Order business protocol with
the Registry using the LifeCycleManager service of the Registry described in Section 7.3.
482
5.2.3 Seller’s Collaboration Protocol Profile Is Submitted
483
484
485
486
The seller publishes its Collaboration Protocol Profile or CPP as defined by [ebCPP] to the
Registry. The CPP describes the seller, the role it plays, the services it offers and the technical
details on how those services may be accessed. The seller classifies their Collaboration Protocol
Profile using the Registry’s flexible Classification capabilities.
487
5.2.4 Buyer Discovers The Seller
488
489
490
491
The buyer browses the Registry using Classification schemes defined within the Registry using a
Registry Browser GUI tool to discover a suitable seller. For example the buyer may look for all
parties that are in the Automotive Industry, play a seller role, support the RosettaNet PIP3A4
process and sell Car Stereos.
492
The buyer discovers the seller’s CPP and decides to engage in a partnership with the seller.
Copyright © OASIS, 2002. All Rights Reserved
Page 16 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
493
5.2.5 CPA Is Established
494
495
496
497
498
499
The buyer unilaterally creates a Collaboration Protocol Agreement or CPA as defined by
[ebCPP] with the seller using the seller’s CPP and their own CPP as input. The buyer proposes a
trading relationship to the seller using the unilateral CPA. The seller accepts the proposed CPA
and the trading relationship is established.
Once the seller accepts the CPA, the parties may begin to conduct B2B transactions as defined
by [ebMS].
500
5.3 Registry Users
501
502
503
We describe the actors who use the registry below. Some of the actors are defined in Section
Error! Reference source not found.. Note that the same entity may represent different actors.
For example, a Registration Authority and Registry Administrator may have the same identity.
Table 1: Registry Users
504
Actor
Function
ISO/IEC
11179
Comments
RegistrationAuthority
Hosts the RegistryObjects
Registry
Administrator
Evaluates and enforces
registry security policy.
Facilitates definition of the
registry security policy.
MAY have the same
identity as
Registration
Authority
Registered User
Has a contract with the
Registration Authority and
MUST be authenticated by
Registration Authority.
The contract could
be a ebXML CPA or
some other form of
contract.
Registry Guest
Has no contract with
Registration Authority. Does
not have to be authenticated
for Registry access. Cannot
change contents of the
Registry (MAY be permitted
to read some
RegistryObjects.)
A Registered User who does
lifecycle operations on
permitted RegistryObjects.
A Registered User who has
only read access
Creates Registry Objects
Note that a Registry
Guest is not a
Registry Reader.
Submitting
Organization
Registry Reader
Responsible
Organization
Copyright © OASIS, 2002. All Rights Reserved
Registration
Authority (RA)
Submitting
Organization
(SO)
Responsible
Organization
(RO)
RO MAY have the
same identity as SO
Page 17 of 188
OASIS/ebXML Registry Services Specification v3.0
Registry Client
July 2017
Registered User or Registered
Guest
505
506
Figure 1: Actor Relationships
507
508
Note:
In the current version of the specification the following are true.
509
A Submitting Organization and a Responsible Organization are the same.
510
Registration of a user happens out-of-band, i.e, by means not specified in this specification.
511
A Registry Administrator and Registration Authority are the same.
512
5.4 Where the Registry Services May Be Implemented
513
514
The Registry Services may be implemented in several ways including, as a public web site, as a
private web site, hosted by an ASP or hosted by a VPN provider.
515
5.5 Implementation Conformance
516
517
518
519
520
521
522
An implementation is a conforming ebXML Registry if the implementation meets the conditions
in Section 5.5.1. An implementation is a conforming ebXML Registry Client if the
implementation meets the conditions in Section 5.5.2. An implementation is a conforming
ebXML Registry and a conforming ebXML Registry Client if the implementation conforms to
the conditions of Section 5.5.1 and Section 5.5.2. An implementation shall be a conforming
ebXML Registry, a conforming ebXML Registry Client, or a conforming ebXML Registry and
Registry Client.
523
5.5.1 Conformance as an ebXML Registry
524
525
An implementation conforms to this specification as an ebXML Registry if it meets the
following conditions:
Copyright © OASIS, 2002. All Rights Reserved
Page 18 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
526
1. Conforms to the ebXML Registry Information Model [ebRIM].
527
2. Supports the syntax and semantics of the Registry Interfaces and Security Model.
528
3. Supports the defined ebXML Registry Schema (Appendix B).
529
4. Optionally supports the syntax and semantics of Section 8.3, SQL Query Support.
530
5.5.2 Conformance as an ebXML Registry Client
531
532
An implementation conforms to this specification, as an ebXML Registry Client if it meets the
following conditions:
533
1. Supports the ebXML CPA and bootstrapping process.
534
2. Supports the syntax and the semantics of the Registry Client Interfaces.
535
3. Supports the defined ebXML Error Message DTD.
536
537
4. Supports the defined ebXML Registry Schema (Appendix B).
Copyright © OASIS, 2002. All Rights Reserved
Page 19 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
538
6 ebXML Registry Architecture
539
540
541
542
543
The ebXML Registry architecture consists of an ebXML Registry Service and ebXML Registry
Clients. The ebXML Registry Service provides the methods for managing a repository. An
ebXML Registry Client is an application used to access the Registry.
544
6.1 Registry Service Described
545
546
547
548
549
550
551
The ebXML Registry Service is comprised of a robust set of interfaces designed to
fundamentally manage the objects and inquiries associated with the ebXML Registry. The two
primary interfaces for the Registry Service consist of:
A Lifecycle Management interface that provides a collection of methods for managing
objects within the Registry.
A Query Management Interface that controls the discovery and retrieval of information from
the Registry.
552
553
554
A registry client program utilizes the services of the registry by invoking methods on one of the
above interfaces defined by the Registry Service. This specification defines the interfaces
exposed by the Registry Service as well as the interface for the Registry Client.
555
6.2 Abstract Registry Service
556
The architecture defines the ebXML Registry as an abstract registry service that is defined as:
557
1. A set of interfaces that must be supported by the registry.
558
2. The set of methods that must be supported by each interface.
559
3. The parameters and responses that must be supported by each method.
560
561
562
The abstract registry service neither defines any specific implementation for the ebXML
Registry, nor does it specify any specific protocols used by the registry. Such implementation
details are described by concrete registry services that realize the abstract registry service.
563
564
565
The abstract registry service (Figure 3) shows how an abstract ebXML Registry must provide
two key functional interfaces called QueryManager1 (QM) and LifeCycleManager2
(LM).
Figure 2: ebXML Registry Service Architecture
566
567
Figure 3: The Abstract ebXML Registry Service
1
Known as ObjectQueryManager in V1.0
2
Known as ObjectManager in V1.0
Copyright © OASIS, 2002. All Rights Reserved
Page 20 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
568
569
0 provides hyperlinks to the abstract service definition in the Web Service Description Language
(WSDL) syntax.
570
6.2.1 LifeCycleManager Interface
571
572
573
574
575
This is the interface exposed by the Registry Service that implements the object lifecycle
management functionality of the Registry. Its methods are invoked by the Registry Client. For
example, the client may use this interface to submit objects, to classify and associate objects and
to deprecate and remove objects. For this specification the semantic meaning of submit, classify,
associate, deprecate and remove is found in [ebRIM].
576
Table 2: LifeCycle Manager Summary
Method Summary of LifeCycleManager
RegistryResponse acceptObjects(AcceptObjectsRequest req)
Accepts one or more objects to a registry during object
relocation.
RegistryResponse approveObjects(ApproveObjectsRequest req)
Approves one or more previously submitted objects.
RegistryResponse deprecateObjects(DeprecateObjectsRequest req)
Deprecates one or more previously submitted objects.
RegistryResponse removeObjects(RemoveObjectsRequest req)
Removes one or more previously submitted objects from
the Registry.
RegistryResponse submitObjects(SubmitObjectsRequest req)
Submits one or more objects and possibly related
metadata such as Associations and Classifications.
RegistryResponse updateObjects(UpdateObjectsRequest req)
Updates one or more previously submitted objects.
RegistryResponse addSlots(AddSlotsRequest req)
Add slots to one or more registry entries.
RegistryResponse relocateObjects(RelocateObjectsRequest req)
Relocate one or more objects from one registry to
another.
RegistryResponse removeSlots(RemoveSlotsRequest req)
Remove specified slots from one or more registry entries.
577
6.2.2 QueryManager Interface
578
579
580
This is the interface exposed by the Registry that implements the Query management service of
the Registry. Its methods are invoked by the Registry Client. For example, the client may use this
interface to perform browse and drill down queries or ad hoc queries on registry content.
581
Table 3: Query Manager
Method Summary of QueryManager
Copyright © OASIS, 2002. All Rights Reserved
Page 21 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
GetContentResponse getContent(GetContentRequest req)
Submit an ad hoc query request. This method is being
deprecated and may go away in version 4.
GetNotificationsResponse getNotifications(GetNotificationsRequest req)
Submit a request to get event notifications.
AdhocQueryResponse submitAdhocQuery(AdhocQueryRequest req)
Submit an ad hoc query request.
RegistryObject getRegistryObject(String id)
Submit a request to get the RegistryObject that matches
the specified id.
RepositoryItem getRepositoryItem(String id)
Submit a request to get the repository item that matches
the specified id. This is the same as the id of the
ExtrinsicObject that catalogs this repository item.
582
583
6.3 Concrete Registry Services
584
585
586
587
The architecture allows the abstract registry service to be mapped to one or more concrete
registry services defined as:
Implementations of the interfaces defined by the abstract registry service.
Bindings of these concrete interfaces to specific communication protocols.
588
589
590
591
This specification describes the following concrete bindings for the abstract registry service:
A SOAP binding using the HTTP protocol
An ebXML Messaging Service (ebMS) binding
An HTTP binding
592
593
594
A registry must implement at least one concrete binding between SOAP and ebMS concrete
bindings for the abstract registry service as shown in Figure 4. In addition a registry must
implement the HTTP binding for the abstract registry service as shown in Figure 4.
595
596
597
598
599
Figure 4: A Concrete ebXML Registry Service
Figure 4 shows a concrete implementation of the abstract ebXML Registry (RegistryService) on
the left side. The RegistryService provides the QueryManager and LifeCycleManager interfaces
Copyright © OASIS, 2002. All Rights Reserved
Page 22 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
600
available with multiple protocol bindings (SOAP and ebMS).
601
602
603
604
Figure 4 also shows two different clients of the ebXML Registry on the right side. The top client
uses SOAP interface to access the registry while the lower client uses ebMS interface. Clients
use the appropriate concrete interface within the RegistryService service based upon their
protocol preference.
605
6.4 SOAP Binding
606
6.4.1 WSDL Terminology Primer
607
608
609
610
611
612
613
This section provides a brief introduction to Web Service Description Language (WSDL) since
the SOAP binding is described using WSDL syntax. WSDL provides the ability to describe a
web service in abstract as well as with concrete bindings to specific protocols. In WSDL, an
abstract service consists of one or more port types or end-points. Each port type consists
of a collection of operations. Each operation is defined in terms of messages that define
what data is exchanged as part of that operation. Each message is typically defined in terms of
elements within an XML Schema definition.
614
615
616
617
618
An abstract service is not bound to any specific protocol (e.g. SOAP). In WSDL, an abstract
service may be used to define a concrete service by binding it to a specific protocol. This binding
is done by providing a binding definition for each abstract port type that defines additional
protocols specific details. Finally, a concrete service definition is defined as a collection of
ports, where each port simply adds address information such as a URL for each concrete port.
619
6.4.2 Concrete Binding for SOAP
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
This section assumes that the reader is somewhat familiar with SOAP and WSDL. The SOAP
binding to the ebXML Registry is defined as a web service description in WSDL as follows:
A single service element with name “RegistryService” defines the concrete SOAP binding
for the registry service.
The service element includes two port definitions, where each port corresponds with one of
the interfaces defined for the abstract registry service. Each port includes an HTTP URL for
accessing that port.
Each port definition also references a binding element, one for each interface defined in the
WSDL for the abstract registry service.
640
The complete WSDL description for the SOAP binding can be obtained via a hyperlink in 0.
<service name = "RegistryService">
<port name = "QueryManagerSOAPBinding" binding = "tns:QueryManagerSOAPBinding">
<soap:address location = "http://your_URL_to_your_QueryManager"/>
</port>
<port name = "LifeCycleManagerSOAPBinding" binding = "tns:LifeCycleManagerSOAPBinding">
<soap:address location = "http://your_URL_to_your_QueryManager"/>
</port>
</service>
Copyright © OASIS, 2002. All Rights Reserved
Page 23 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
641
6.5 ebXML Message Service Binding
642
6.5.1 Service and Action Elements
643
644
645
646
647
648
649
650
651
652
653
When using the ebXML Messaging Services Specification, ebXML Registry Service elements
correspond to Messaging Service elements as follows:
The value of the Service element in the MessageHeader is an ebXML Registry Service
interface name (e.g., “LifeCycleManager”). The type attribute of the Service element should
have a value of “ebXMLRegistry”.
The value of the Action element in the MessageHeader is an ebXML Registry Service
method name (e.g., “submitObjects”).
654
655
656
Note that the above allows the Registry Client only one interface/method pair per message. This
implies that a Registry Client can only invoke one method on a specified interface for a given
request to a registry.
657
6.5.2 Synchronous and Asynchronous Responses
658
All methods on interfaces exposed by the registry return a response message.
659
Asynchronous response
660
661
662
663
664
665
When a message is sent asynchronously, the Registry will return two response messages. The
first message will be an immediate response to the request and does not reflect the actual
response for the request. This message will contain:
MessageHeader
RegistryResponse element including:
o status attribute with value Unavailable
666
667
668
669
670
671
672
673
The Registry delivers the actual Registry response element with non-empty content
asynchronously at a later time. The delivery is accomplished by the Registry invoking the
onResponse method on the RegistryClient interface as implemented by the registry client
application. The onResponse method includes a RegistryResponse element as shown below:
MessageHeader
RegistryResponse element including:
o Status attribute (Success, Failure)
o Optional RegistryErrorList
674
Synchronous response
675
676
677
678
When a message is sent synchronously, the Message Service Handler will hold open the
communication mechanism until the Registry returns a response. This message will contain:
MessageHeader
RegistryResponse element including:
<eb:Service eb:type=”ebXMLRegistry”>LifeCycleManger</eb:Service>
<eb:Action>submitObjects</eb:Action>
Copyright © OASIS, 2002. All Rights Reserved
Page 24 of 188
OASIS/ebXML Registry Services Specification v3.0
679
680
July 2017
o Status attribute (Success, Failure)
o Optional RegistryErrorList
681
6.5.3 ebXML Registry Collaboration Profiles and Agreements
682
683
684
685
The ebXML CPP specification [ebCPP] defines a Collaboration-Protocol Profile (CPP) and a
Collaboration-Protocol Agreement (CPA) as mechanisms for two parties to share information
regarding their respective business processes. That specification assumes that a CPA has been
agreed to by both parties in order for them to engage in B2B interactions.
686
687
688
689
This specification does not mandate the use of a CPA between the Registry and the Registry
Client. However if the Registry does not use a CPP, the Registry shall provide an alternate
mechanism for the Registry Client to discover the services and other information provided by a
CPP. This alternate mechanism could be a simple URL.
690
691
692
The CPA between clients and the Registry should describe the interfaces that the Registry and
the client expose to each other for Registry-specific interactions. The definition of the Registry
CPP template and a Registry Client CPP template are beyond the scope of this document.
693
6.6 HTTP Binding
694
695
696
697
698
699
700
The ebXML Registry abstract interface defines a HTTP binding that enables access to the
registry over HTTP protocol. The HTTP binding maps the abstract registry interfaces to an
HTTP interface. It defines the URI parameters and their usage patterns that must be used to
specify the interface, method and invocation parameters in order to invoke a method on a registry
interface such as the QueryManager interface.
The HTTP binding also defines the return values that are synchronously sent back to the client as
the HTTP response for the HTTP request.
701
6.6.1 Standard URI Parameters
702
703
704
This section defines the normative URI parameters that must be supported by the HTTP
Interface. A Registry may implement additional URI parameters in addition to these parameters.
URI Parameter
Name
705
Required
Description
Example
interface
YES
Defines the interface or object
Example: QueryManager
to call methods on.
method
YES
Defines the method to be
carried out on the given
interface.
Example:
submitAdhocQueryRequest
param-<key>
NO
Defines named parameters to
be passed into a method call.
Example: param-id=888-9998877h
Table 4: Standard URI Parameters
706
Copyright © OASIS, 2002. All Rights Reserved
Page 25 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
707
6.6.2 QueryManager HTTP Interface
708
709
710
711
712
The HTTP Interface to QueryManager must be supported by all registries.
The HTTP Interface to QueryManager defines that the interface parameter must be
"QueryManager". In addition the following method parameters are defined by the QueryManager
HTTP Interface.
Parameters
Method
getNotifications
Return Value
GetNotificationsRequest GetNotificationsResponse
POST
Id
An instance of a leaf class that
is a concrete sub-class of
GET
RegistryObject that matches the
specified id.
Id
RepositoryItem that matches
the specified id. Note that a
RepositoryItem may be
arbitrary content (e.g. a GIF
image).
getRegistryObject
getRepositoryItem
submitAdhocQueryRequest
HTTP
Request
Type
AdhocQueryRequest
GET
AdhocQueryResponse for the
POST
specified AdhocQueryRequest.
Table 5: QueryManager HTTP Interface
713
714
715
716
Note that in the examples that follow name space declarations are omitted to conserve space.
Also note that some lines may be wrapped due to lack of space.
717
Sample getRegistryObject Request
718
719
720
721
722
The following example shows a getRegistryObject request.
723
Sample getRegistryObject Response
724
725
726
727
728
729
730
731
732
733
734
The following example shows an ExtrinsicObject, which is a specialized sub-class of
RegistryObject being returned as a response to the getRegistryObject method invocation.
GET /http?interface=QueryManager&method=getRegistryObject¶m-id=
urn:uuid:a1137d00-091a-471e-8680-eb75b27b84b6 HTTP/1.1
HTTP/1.1 200 OK
Content-Type: text/xml
Content-Length: 555
<?xml version="1.0"?>
<ExtrinsicObject id = "urn:uuid:a1137d00-091a-471e-8680-eb75b27b84b6"
objectType="urn:uuid:32bbb291-0291-486d-a80d-cdd6cd625c57">
<Name>
Copyright © OASIS, 2002. All Rights Reserved
Page 26 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
735
736
737
738
<LocalizedString value = "Sample Object"/>
</Name>
</ExtrinsicObject>
739
Sample getRepositoryItem Request
740
741
742
743
744
The following example shows a getRepositoryItem request.
745
Sample getRepositoryItem Response
746
747
748
749
750
751
752
753
754
755
756
757
The following example assumes that the repository item was a Collaboration Protocol Profile as
defined by [ebCPP].
758
Sample submitAdhocQueryRequest Request
759
760
761
762
763
764
765
766
767
768
769
770
771
772
The following example shows how an HTTP POST request is used to invoke the
submitAdhocQueryRequest method of QueryManager.
773
Sample submitAdhocQueryRequest Response
774
775
776
777
778
779
780
781
The following example shows an AdhocQueryResponse that is returned in response to an
AdhocQueryRequest.
GET /http?interface=QueryManager&method=getRepositoryItem¶m-id=
urn:uuid:a1137d00-091a-471e-8680-eb75b27b84b6 HTTP/1.1
HTTP/1.1 200 OK
Content-Type: text/xml
Content-Length: 555
<?xml version="1.0"?>
< CollaborationProtocolProfile>
...
</CollaborationProtocolProfile>
POST /http?interface=QueryManager&method=submitAdhocQueryRequest HTTP/1.1
User-Agent: Foo-ebXML/1.0
Host: www.registryserver.com
Content-Type: text/xml
Content-Length: 555
<?xml version="1.0"?>
<AdhocQueryRequest>
...
</AdhocQueryRequest>
HTTP/1.1 200 OK
Content-Type: text/xml
Content-Length: 555
<?xml version="1.0"?>
Copyright © OASIS, 2002. All Rights Reserved
Page 27 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
782
783
784
785
<AdhocQueryResponse>
...
</AdhocQueryResponse>
786
6.6.3 LifeCycleManager HTTP Interface
787
788
789
790
791
The HTTP Interface to LifeCycleManager may be supported by a registry.
The HTTP Interface to LifeCycleManager defines that the interface parameter must be
"LifeCycleManager". In addition the following method parameters are defined by the
LifeCycleManager HTTP Interface.
Method
acceptObjects
792
Parameters
AcceptObjectsRequest
Return Value
HTTP Request Type
RegistryResponse
POST
approveObjects ApproveObjectsRequest RegistryResponse
POST
deprecateObjects DeprecateObjectsRequest RegistryResponse
POST
relocateObjects
RelocateObjectsRequest RegistryResponse
POST
removeObjects
RemoveObjectsRequest
RegistryResponse
POST
submitObjects
SubmitObjectsRequest
RegistryResponse
POST
updateObjects
UpdateObjectsRequest
RegistryResponse
POST
addSlots
AddSlotsRequest
RegistryResponse
POST
removeSlots
RemoveSlotsRequest
RegistryResponse
POST
Table 6: LifeCycleManager HTTP Interface
793
794
Note that in the examples that follow name space declarations are omitted to conserve space.
Also note that some lines may be wrapped due to lack of space.
795
Sample submitObjects Request
796
797
798
799
800
801
802
803
804
805
806
807
808
809
The following example shows how an HTTP POST request is used to invoke the submitObjects
method in LifeCycleManager.
POST /http?interface=LifeCycleManager&method=submitObjects HTTP/1.1
User-Agent: Foo-ebXML/1.0
Host: www.registryserver.com
Content-Type: text/xml
Content-Length: 555
<?xml version="1.0"?>
<SubmitObjectsRequest>
...
</SubmitObjectRequest>
Copyright © OASIS, 2002. All Rights Reserved
Page 28 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
810
Sample submitObjects Response
811
812
813
814
815
816
817
818
819
820
821
822
The following example shows a sample response returned by the submitObjects method in
LifeCycleManager.
823
6.6.4 Security Considerations
824
825
826
827
828
829
The HTTP interface supports the same mechanisms that are specified in chapter 12.
Authentication may be performed by the registry on a per message basis by verifying any digital
signatures present, as well as at the HTTP transport level using Basic or Digest authentication.
When using the HTTP binding, authentication credentials are specified using the SignatureList
element within a request or response as defined by the RegistryRequestType (6.9.1) and
RegistryResponseType (6.9.2) elements in the registry XML schema.
830
6.6.5 Exception Handling
831
832
833
834
835
836
837
838
839
840
Exception handling is consistent with exception handling in other registry interface bindings.
Errors must be reported in a RegistryErrorList, and sent back to the client on the same
connection as the request.
When errors occur, the HTTP status code and message should correspond to the error(s) being
reported in the RegistryErrorList. For example, if the RegistryErrorList reports that an
object wasn't found, therefore cannot be returned, an appropriate error code should be 404, with a
message of "ObjectNotFoundException". A detailed list of HTTP status codes can be found in
[RFC2616]. The mapping between registry exceptions and HTTP status codes is currently
unspecified.
841
6.7 Registry Clients
842
6.7.1 Registry Client Described
843
844
845
846
847
848
849
850
851
The Registry Client interfaces may be local to the registry or local to the user. Figure 5 depicts
the two possible topologies supported by the registry architecture with respect to the Registry
and Registry Clients. The picture on the left side shows the scenario where the Registry provides
a web based “thin client” application for accessing the Registry that is available to the user using
a common web browser. In this scenario the Registry Client interfaces reside across the Internet
and are local to the Registry from the user’s view. The picture on the right side shows the
scenario where the user is using a “fat client” Registry Browser application to access the registry.
In this scenario the Registry Client interfaces reside within the Registry Browser tool and are
local to the Registry from the user’s view. The Registry Client interfaces communicate with the
HTTP/1.1 200 OK
Content-Type: text/xml
Content-Length: 555
<?xml version="1.0"?>
<RegistryResponse>
...
</RegistryResponse>
Copyright © OASIS, 2002. All Rights Reserved
Page 29 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
852
Registry over the Internet in this scenario.
853
854
855
856
857
A third topology made possible by the registry architecture is where the Registry Client
interfaces reside in a server side business component such as a Purchasing business component.
In this topology there may be no direct user interface or user intervention involved. Instead, the
Purchasing business component may access the Registry in an automated manner to select
possible sellers or service providers based on current business needs.
858
859
Figure 5: Registry Architecture Supports Flexible Topologies
860
6.7.2 Registry Communication Bootstrapping
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
Before a client can access the services of a Registry, there must be some communication
bootstrapping between the client and the registry. The most essential aspect of this bootstrapping
process is for the client to discover addressing information (e.g. an HTTP URL) to each of the
concrete service interfaces of the Registry. The client may obtain the addressing information by
discovering the ebXML Registry in a public registry such as UDDI or within another ebXML
Registry.
In case of SOAP binding, all the info needed by the client (e.g. Registry URLs) is available
in a WSDL desription for the registry. This WSDL conforms to the template WSDL
description in Appendix A.1. This WSDL description may be discovered in a in a registry of
registries.
In case of ebMS binding, the information exchange between the client and the registry may
be accomplished in a registry specific manner, which may involve establishing a CPA
between the client and the registry. Once the information exchange has occurred the Registry
and the client will have addressing information (e.g. URLs) for the other party.
In case of HTTP binding the client may obtain the base URL to the registry by a lookup in a
registry of registries.
Copyright © OASIS, 2002. All Rights Reserved
Page 30 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
877
878
Communication Bootstrapping for SOAP Binding
879
880
881
882
Each ebXML Registry must provide a WSDL description for its RegistryService as defined by
Appendix A.1. A client uses the WSDL description to determine the address information of the
RegistryService in a protocol specific manner. For example the SOAP/HTTP based ports of the
RegistryService may be accessed via a URL specified in the WSDL for the registry.
883
884
The use of WSDL enables the client to use automated tools such as a WSDL compiler to
generate stubs that provide access to the registry in a language specific manner.
885
886
887
At minimum, any client may access the registry over SOAP/HTTP using the address information
within the WSDL, with minimal infrastructure requirements other than the ability to make
synchronous SOAP call to the SOAP based ports on the RegistryService.
888
Communication Bootstrapping for ebXML Message Service Binding
889
890
891
892
893
894
895
896
897
898
Since there is no previously established CPA between the Registry and the RegistryClient, the
client must know at least one Transport-specific communication address for the Registry. This
communication address is typically a URL to the Registry, although it could be some other type
of address such as an email address. For example, if the communication used by the Registry is
HTTP, then the communication address is a URL. In this example, the client uses the Registry’s
public URL to create an implicit CPA with the Registry. When the client sends a request to the
Registry, it provides a URL to itself. The Registry uses the client’s URL to form its version of an
implicit CPA with the client. At this point a session is established within the Registry. For the
duration of the client’s session with the Registry, messages may be exchanged bi-directionally as
required by the interaction protocols defined in this specification.
899
Communication Bootstrapping for HTTP Binding
900
901
Communication between a client and the HTTP interface is established based upon the base URL
of the HTTP interface to the registry. No other communication bootstrapping is required.
902
6.7.3 RegistryClient Interface
903
904
905
906
907
This is the principal interface implemented by a Registry client. The client provides this interface
when creating a connection to the Registry. It provides the methods that are used by the Registry
to deliver asynchronous responses to the client. Note that a client need not provide a
RegistryClient interface if the [CPA] between the client and the registry does not support
asynchronous responses.
908
The registry sends all asynchronous responses to operations via the onResponse method.
909
Table 7: RegistryClient Summary
Method Summary of RegistryClient
void onResponse(RegistryResponse resp)
Notifies client of the response sent by registry to previously submitted request.
Copyright © OASIS, 2002. All Rights Reserved
Page 31 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
910
6.7.4 Registry Response
911
912
The RegistryResponse is a common class defined by the Registry interface that is used by the
registry to provide responses to client requests.
913
6.8 Interoperability Requirements
914
6.8.1 Client Interoperability
915
916
917
The architecture requires that any ebXML compliant registry client can access any ebXML
compliant registry service in an interoperable manner. An ebXML Registry must implement a
HTTP binding and either or both of the ebMS and SOAP/HTTP bindings.
918
6.9 Registry Requests and Responses
919
920
921
922
923
924
925
926
927
This section describes the generic aspects that are common to all requests/responses
sent/received by registry clients/registry to the registry/registry clients.
Each registry request is atomic and either succeeds or fails in total. In the event of success, the
registry sends a RegistryResponse with a status of “Success” back to the client. In the event of
failure, the registry sends a RegistryResponse with a status of “Failure” back to the client. In the
event of an immediate response for an asynchronous request, the registry sends a
RegistryResponse with a status of “Unavailable” back to the client. Failure occurs when one or
more Error conditions are raised in the processing of the submitted objects. Warning messages
do not result in failure of the request.
928
6.9.1 RegistryRequestType
929
The RegistryRequestType is used as a common base type for all registry requests.
930
Syntax:
931
932
Figure 6: RegistryRequestType Syntax
933
Parameters:
934
935
936
id: This parameter specifies a request identifier that is used by the corresponding
response to correlate the response with its request. It may also be used to correlate
a request with another related request.
937
938
939
RequestSlotList: This parameter specifies a collection of Slot instances. A
RegistryReuqestType may include Slots as an extensibility mechanism that
provides a means of adding dynamic attributes in form of Slots.
Copyright © OASIS, 2002. All Rights Reserved
Page 32 of 188
OASIS/ebXML Registry Services Specification v3.0
940
941
942
July 2017
SignatureList: This parameter specifies a collection of Signature elements as
defined by [XMLDSIG]. Each Signature specified in the SignatureList must be
verified by the registry before processing the request.
943
944
Returns:
945
946
All RegistryRequests returns a response derived from the common RegistryResponseType base
type.
947
Exceptions:
948
The following exceptions are common to all requests:
949
950
AuthorizationException: Indicates that the requestor attempted to perform an
operation for which she was not authorized.
951
952
InvalidRequestException: Indicates that the requestor attempted to perform an
operation that was semantically invalid.
953
954
SignatureValidationException: Indicates that a Signature specified for the request
failed to validate.
955
956
TimeoutException: Indicates that the processing time for the request exceeded a
registry specific limit.
957
958
959
UnsupportedCapabilityException: Indicates that this registry did not support the
capability required to service the request.
960
6.9.2 RegistryResponseType
961
The RegistryResponseType is used as a common base type for all registry responses.
962
963
Syntax:
964
965
Figure 7: RegistryResponseType Syntax
966
Parameters:
967
968
requestId: This parameter specifies the id of the request for which this is a
response. It matches value of the id attribute of the corresponding
Copyright © OASIS, 2002. All Rights Reserved
Page 33 of 188
OASIS/ebXML Registry Services Specification v3.0
969
July 2017
RegistryRequestType.
970
971
972
973
RegistryErrorList: This parameter specifies an optional collection of
RegistryError elements in the event that there are one or more errors that were
encountered while the registry processed the request for this response. This is
described in more detail in 6.9.3.
974
975
976
ResponseSlotList: This parameter specifies a collection of Slot instances. A
RegistryResponseType may include Slots as an extensibility mechanism that
provides a means of adding dynamic attributes in form of Slots.
977
978
979
SignatureList: This parameter specifies a collection of Signature elements as
defined by [DSIG]. Each Signature specified in the SignatureList should be
verified by the receiver before processing the response.
980
981
982
983
984
985
986
987
988
989
status: This enumerated value is used to indicate the status of the request. Values
for status are as follows:
990
.
Success - This status specifies that the request was successful.
Failure - This status specifies that the request encountered a failure. One or
more errors must be included in the RegistryErrorList in this case.
Unavailable – This status specifies that the response is not yet available. This
may be the case if this RegistryResponseType represents an immediate
response to an asynchronous request where the actual response is not yet
available.
991
6.9.3 RegistryResponse
992
993
994
RegistryResponse is an element whose base type is RegistryResponseType. It adds no additional
elements or attributes beyond those described in RegistryResponseType. RegistryResponse is
used by many requests as their response.
995
6.9.4 RegistryErrorList
996
997
A RegistryErrorList specifies an optional collection of RegistryError elements in the event that
there are one or more errors that were encountered while the registry processes a request.
998
999
1000
1001
Syntax:
Figure 8: RegistryErrorList Syntax
Copyright © OASIS, 2002. All Rights Reserved
Page 34 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
1002
Parameters:
1003
1004
1005
highestSeverity: This parameter specifies the ErrorType for the highest severity
RegistryError in the RegistryErrorList. Values for highestSeverity are defined by
ErrorType in 6.9.6.
1006
1007
1008
RegistryError: A RegistryErrorList has one or more RegistryErrors. A
RegistryError specifies an error or warning message that is encountered while the
registry processes a request. RegistryError is defined in 6.9.5.
1009
1010
6.9.5 RegistryError
1011
1012
A RegistryError specifies an error or warning message that is encountered while the registry
processes a request.
1013
1014
Syntax:
1015
1016
Figure 9: RegistryError Syntax
1017
Parameters:
1018
1019
1020
1021
codeContext: This parameter specifies a string that indicates contextual text that
provides additional detail to the errorCode. For example, if the errorCode is
InvalidRequestException the codeContext may provide the reason why the
request was invalid.
1022
1023
1024
errorCode: This parameter specifies a string that indicates the error that was
encountered. Implementations must set this parameter to the Exception or Error as
defined by this specification (e.g. InvalidRequestException).
1025
1026
1027
location: This parameter specifies a string that indicated where in the code the
error occured. Implementations should show the stack trace and/or, code module
and line number information where the error was encountered in code.
1028
1029
1030
severity: This parameter specifies an enumerated value of type ErrorType which
indicates the severity of error that was encountered. ErrorType is described in
6.9.6.
1031
1032
6.9.6 ErrorType
1033
1034
1035
The ErrorType type defines a set of enumerated values that indicate the different type of errors
that a registry may encounter while processing a request. The possible values are Warning and
Error.
Copyright © OASIS, 2002. All Rights Reserved
Page 35 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
1036
Warning
1037
1038
1039
A Warning is a non-fatal error encountered by the registry while processing a request. A registry
must return a status of Success in the RegistryResponse for a request that only encountered
Warnings during its processing and encountered no Errors.
1040
Error
1041
1042
1043
1044
1045
An Error is a fatal error encountered by the registry while processing a request. A registry must
return a status of Failure in the RegistryResponse for a request that encountered Errors during its
processing.
Copyright © OASIS, 2002. All Rights Reserved
Page 36 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
1046
7 Lifecycle Management Service
1047
1048
1049
1050
1051
1052
This section defines the Lifecycle Management service of the Registry. The Lifecycle
Management Service is a sub-service of the Registry service. It provides the functionality
required by RegistryClients to manage the lifecycle of repository items (e.g. XML documents
required for ebXML business processes). The Lifecycle Management Service can be used with
all types of repository items as well as the metadata objects specified in [ebRIM] such as
Classification and Association.
1053
1054
1055
The minimum-security policy for an ebXML registry is to accept content from any client if a
certificate issued by a Certificate Authority recognized by the ebXML registry digitally signs the
content.
1056
7.1 Lifecycle of a RegistryObject
1057
1058
The main purpose of the LifeCycleManagement service is to manage the lifecycle of
RegistryObjects. Figure 10 shows the typical lifecycle of a RegistryObject.
1059
1060
Figure 10: Lifecycle of a RegistryObject
1061
7.2 RegistryObject Attributes
1062
1063
1064
1065
1066
A repository item is associated with a set of standard metadata defined as attributes of the
RegistryObject class and its sub-classes as described in [ebRIM]. These attributes reside outside
of the actual repository item and catalog descriptive information about the repository item. XML
elements called ExtrinsicObject and other elements (See Appendix B.1 for details) encapsulate
all object metadata attributes defined in [ebRIM] as XML attributes.
Copyright © OASIS, 2002. All Rights Reserved
Page 37 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
1067
7.3 The Submit Objects Protocol
1068
1069
1070
This section describes the protocol of the Registry Service that allows a RegistryClient to submit
one or more RegistryObjects and/or repository items using the LifeCycleManager on behalf of a
Submitting Organization. It is expressed in UML notation as described in Appendix A.
1071
1072
Figure 11: Submit Objects Sequence Diagram
1073
For details on the schema for the Business documents shown in this process refer to Appendix B.
1074
7.3.1 SubmitObjectsRequest
1075
1076
The SubmitObjectsRequest is used by a client to submit RegistryObjects and/or repository items
to the registry.
1077
Syntax:
1078
1079
1080
Figure 12: SubmitObjectsRequest Syntax
Parameters:
1081
1082
1083
1084
1085
LeafRegistryObjectsList: This parameter specifies a collection of RegistryObject
instances that are being submitted to the registry. The RegistryObjects in the list
may be brand new objects being submitted to the registry or they may be current
objects already existing in the registry. In case of existing objects the registry
Copyright © OASIS, 2002. All Rights Reserved
Page 38 of 188
OASIS/ebXML Registry Services Specification v3.0
1086
1087
July 2017
must treat them in the same manner as UpdateObjectsRequest and simply update
the existing objects.
1088
1089
Returns:
1090
This request returns a RegistryResponse. See section 7.3.2 for details.
1091
Exceptions:
1092
In addition to the exceptions common to all requests, the following exceptions may be returned:
1093
1094
AuthorizationException: Indicates that the requestor attempted to perform an
operation for which she was not authorized.
1095
1096
ObjectNotFoundException: Indicates that the requestor referenced an object
within the request that was not found.
1097
1098
ObjectExistsException: Indicates that the requestor tried to submit an object using
an id that matched the id of an existing object in the registry.
1099
1100
InvalidRequestException: Indicates that the requestor attempted to perform an
operation which was semantically invalid.
1101
1102
UnsupportedCapabilityException: Indicates that the requestor attempted to
submit some content that is not supported by the registry.
1103
1104
QuotaExceededException: Indicates that the requestor attempted to submit more
content than the quota allowed for them by the registry.
1105
1106
7.3.2 RegistryResponse
1107
1108
1109
1110
The RegistryResponse is sent by the registry as a response to several different requests. It is a
simple response that can signal the status of a request and any errors or exceptions that may have
occurred during the processing of that request. The details of RegistryResponse are decsribed by
the RegistryResponseType in 6.9.2.
1111
7.3.3 Universally Unique ID Generation
1112
1113
1114
1115
As specified by [ebRIM], all objects in the registry have a unique id contained within the value
of the “id” attribute of a RegistryObject instance. The id must be a Universally Unique Identifier
(UUID) and must conform to the format of a URN that specifies a DCE 128 bit UUID as
specified in [UUID].
1116
1117
1118
1119
1120
1121
1122
(e.g. urn:uuid:a2345678-1234-1234-123456789012)
The registry usually generates this id. The client may optionally supply the id attribute for
submitted objects. If the client supplies the id and it conforms to the format of a URN that
specifies a DCE 128 bit UUID then the registry assumes that the client wishes to specify the id
for the object. In this case, the registry must honour a client-supplied id and use it as the id
attribute of the object in the registry. If the id is not unique within the registry, the registry must
return ObjectExistsException.
Copyright © OASIS, 2002. All Rights Reserved
Page 39 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
1123
1124
1125
If the client does not supply an id for a submitted object then the registry must generate a
universally unique id. Whether the client generates the id or whether the registry generates it, it
must be generated using the DCE 128 bit UUID generation algorithm as specified in [UUID].
1126
7.3.4 ID Attribute And Object References
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
The id attribute of an object may be used by other objects to reference the first object. Such
references are common both within the SubmitObjectsRequest as well as within the registry.
Within a SubmitObjectsRequest, the id attribute may be used to refer to an object within the
SubmitObjectsRequest as well as to refer to an object within the registry. An object in the
SubmitObjectsRequest that needs to be referred to within the request document may be assigned
an id by the submitter so that it can be referenced within the request. The submitter may give the
object a proper UUID URN, in which case the id is permanently assigned to the object within the
registry. Alternatively, the submitter may assign an arbitrary id (not a proper UUID URN) as
long as the id is a unique anyURI value within the request document. In this case the id serves as
a linkage mechanism within the request document but must be ignored by the registry and
replaced with a registry generated UUID upon submission.
1138
1139
1140
1141
When an object in a SubmitObjectsRequest needs to reference an object that is already in the
registry, the request must contain an ObjectRef whose id attribute is the id of the object in the
registry. This id is by definition a proper UUID URN. An ObjectRef may be viewed as a proxy
within the request for an object that is in the registry.
1142
7.3.5 Audit Trail
1143
1144
The RS must create AuditableEvent objects with eventType Created for each RegistryObject
created via a SubmitObjectsRequest.
1145
7.3.6 Sample SubmitObjectsRequest
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
The following example shows several different use cases in a single SubmitObjectsRequest. It
does not show the complete SOAP or [ebMS] Message with the message header and additional
payloads in the message for the repository items.
A SubmitObjectsRequest includes a RegistryObjectList which contains any number of objects
that are being submitted. It may also contain any number of ObjectRefs to link objects being
submitted to objects already within the registry.
<?xml version = "1.0" encoding = "UTF-8"?>
<SubmitObjectsRequest
xmlns = "urn:oasis:names:tc:ebxml-regrep:registry:xsd:2.0"
xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation = "urn:oasis:names:tc:ebxml-regrep:rim:xsd:2.0 file:///C:/osws/ebxmlrrspec/misc/schema/rim.xsd urn:oasis:names:tc:ebxml-regrep:registry:xsd:2.0
file:///C:/osws/ebxmlrr-spec/misc/schema/rs.xsd"
xmlns:rim = "urn:oasis:names:tc:ebxml-regrep:rim:xsd:2.0"
xmlns:rs = "urn:oasis:names:tc:ebxml-regrep:registry:xsd:2.0"
>
<rim:LeafRegistryObjectList>
<!-The following 3 objects package specified ExtrinsicObject in specified
RegistryPackage, where both the RegistryPackage and the ExtrinsicObject are
being submitted
-->
Copyright © OASIS, 2002. All Rights Reserved
Page 40 of 188
OASIS/ebXML Registry Services Specification v3.0
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
July 2017
<rim:RegistryPackage id = "acmePackage1" >
<rim:Name>
<rim:LocalizedString value = "RegistryPackage #1"/>
</rim:Name>
<rim:Description>
<rim:LocalizedString value = "ACME's package #1"/>
</rim:Description>
</rim:RegistryPackage>
<rim:ExtrinsicObject id = "acmeCPP1" >
<rim:Name>
<rim:LocalizedString value = "Widget Profile" />
</rim:Name>
<rim:Description>
<rim:LocalizedString value = "ACME's profile for selling widgets" />
</rim:Description>
</rim:ExtrinsicObject>
<rim:Association id = "acmePackage1-acmeCPP1-Assoc" associationType = "Packages" sourceObject
= "acmePackage1" targetObject = "acmeCPP1" />
<!-The following 3 objects package specified ExtrinsicObject in specified RegistryPackage,
Where the RegistryPackage is being submitted and the ExtrinsicObject is
already in registry
-->
<rim:RegistryPackage id = "acmePackage2" >
<rim:Name>
<rim:LocalizedString value = "RegistryPackage #2"/>
</rim:Name>
<rim:Description>
<rim:LocalizedString value = "ACME's package #2"/>
</rim:Description>
</rim:RegistryPackage>
<rim:ObjectRef id = "urn:uuid:a2345678-1234-1234-123456789012"/>
<rim:Association id = "acmePackage2-alreadySubmittedCPP-Assoc" associationType = "Packages"
sourceObject = "acmePackage2" targetObject = "urn:uuid:a2345678-1234-1234-123456789012"/>
<!-The following 3 objects package specified ExtrinsicObject in specified RegistryPackage,
where the RegistryPackage and the ExtrinsicObject are already in registry
-->
<rim:ObjectRef id = "urn:uuid:b2345678-1234-1234-123456789012"/>
<rim:ObjectRef id = "urn:uuid:c2345678-1234-1234-123456789012"/>
<!-- id is unspecified implying that registry must create a uuid for this object -->
<rim:Association associationType = "Packages" sourceObject = "urn:uuid:b2345678-1234-1234123456789012" targetObject = "urn:uuid:c2345678-1234-1234-123456789012"/>
<!-The following 3 objects externally link specified ExtrinsicObject using
specified ExternalLink, where both the ExternalLink and the ExtrinsicObject
are being submitted
-->
<rim:ExternalLink id = "acmeLink1" externalURI="http://www.acme.com">
<rim:Name>
<rim:LocalizedString value = "Link #1"/>
</rim:Name>
<rim:Description>
<rim:LocalizedString value = "ACME's Link #1"/>
</rim:Description>
</rim:ExternalLink>
<rim:ExtrinsicObject id = "acmeCPP2" >
<rim:Name>
<rim:LocalizedString value = "Sprockets Profile" />
</rim:Name>
Copyright © OASIS, 2002. All Rights Reserved
Page 41 of 188
OASIS/ebXML Registry Services Specification v3.0
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
July 2017
<rim:Description>
<rim:LocalizedString value = "ACME's profile for selling sprockets"/>
</rim:Description>
</rim:ExtrinsicObject>
<rim:Association id = "acmeLink1-acmeCPP2-Assoc" associationType = "ExternallyLinks"
sourceObject = "acmeLink1" targetObject = "acmeCPP2"/>
<!-The following 2 objects externally link specified ExtrinsicObject using specified
ExternalLink, where the ExternalLink is being submitted and the ExtrinsicObject
is already in registry. Note that the targetObject points to an ObjectRef in a
previous line
-->
<rim:ExternalLink id = "acmeLink2" externalURI="http://www.acme2.com">
<rim:Name>
<rim:LocalizedString value = "Link #2"/>
</rim:Name>
<rim:Description>
<rim:LocalizedString value = "ACME's Link #2"/>
</rim:Description>
</rim:ExternalLink>
<rim:Association id = "acmeLink2-alreadySubmittedCPP-Assoc" associationType =
"ExternallyLinks" sourceObject = "acmeLink2" targetObject = "urn:uuid:a2345678-1234-1234123456789012"/>
<!-The following 3 objects externally identify specified ExtrinsicObject using specified
ExternalIdentifier, where the ExternalIdentifier is being submitted and the
ExtrinsicObject is already in registry. Note that the targetObject points to an
ObjectRef in a previous line
-->
<rim:ClassificationScheme id = "DUNS-id" isInternal="false" nodeType="UniqueCode" >
<rim:Name>
<rim:LocalizedString value = "DUNS"/>
</rim:Name>
<rim:Description>
<rim:LocalizedString value = "This is the DUNS scheme"/>
</rim:Description>
</rim:ClassificationScheme>
<rim:ExternalIdentifier id = "acmeDUNSId" identificationScheme="DUNS-id" value =
"13456789012">
<rim:Name>
<rim:LocalizedString value = "DUNS" />
</rim:Name>
<rim:Description>
<rim:LocalizedString value = "DUNS ID for ACME"/>
</rim:Description>
</rim:ExternalIdentifier>
<rim:Association id = "acmeDUNSId-alreadySubmittedCPP-Assoc" associationType =
"ExternallyIdentifies" sourceObject = "acmeDUNSId" targetObject = "urn:uuid:a2345678-1234-1234123456789012"/>
<!-The following show submission of a brand new classification scheme in its entirety
-->
<rim:ClassificationScheme id = "Geography-id" isInternal="true" nodeType="UniqueCode" >
<rim:Name>
<rim:LocalizedString value = "Geography"/>
</rim:Name>
<rim:Description>
<rim:LocalizedString value = "This is a sample Geography scheme"/>
</rim:Description>
<rim:ClassificationNode id = "NorthAmerica-id" parent = "Geography-id" code =
"NorthAmerica" >
Copyright © OASIS, 2002. All Rights Reserved
Page 42 of 188
OASIS/ebXML Registry Services Specification v3.0
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
July 2017
<rim:ClassificationNode id = "UnitedStates-id" parent = "NorthAmerica-id" code =
"UnitedStates" />
<rim:ClassificationNode id = "Canada-id" parent = "NorthAmerica-id" code = "Canada" />
</rim:ClassificationNode>
<rim:ClassificationNode id = "Asia-id" parent = "Geography-id" code = "Asia" >
<rim:ClassificationNode id = "Japan-id" parent = "Asia-id" code = "Japan" >
<rim:ClassificationNode id = "Tokyo-id" parent = "Japan-id" code = "Tokyo" />
</rim:ClassificationNode>
</rim:ClassificationNode>
</rim:ClassificationScheme>
<!-The following show submission of a Automotive sub-tree of ClassificationNodes that
gets added to an existing classification scheme named 'Industry'
that is already in the registry
-->
<rim:ObjectRef id = "urn:uuid:d2345678-1234-1234-123456789012"/>
<rim:ClassificationNode id = "automotiveNode" parent = "urn:uuid:d2345678-1234-1234123456789012">
<rim:Name>
<rim:LocalizedString value = "Automotive" />
</rim:Name>
<rim:Description>
<rim:LocalizedString value = "The Automotive sub-tree under Industry scheme"/>
</rim:Description>
</rim:ClassificationNode>
<rim:ClassificationNode id = "partSuppliersNode" parent = "automotiveNode">
<rim:Name>
<rim:LocalizedString value = "Parts Supplier" />
</rim:Name>
<rim:Description>
<rim:LocalizedString value = "The Parts Supplier node under the Automotive node" />
</rim:Description>
</rim:ClassificationNode>
<rim:ClassificationNode id = "engineSuppliersNode" parent = "automotiveNode">
<rim:Name>
<rim:LocalizedString value = "Engine Supplier" />
</rim:Name>
<rim:Description>
<rim:LocalizedString value = "The Engine Supplier node under the Automotive node" />
</rim:Description>
</rim:ClassificationNode>
<!-The following show submission of 2 Classifications of an object that is already in
the registry using 2 ClassificationNodes. One ClassificationNode
is being submitted in this request (Japan) while the other is already in the registry.
-->
<rim:Classification id = "japanClassification" classifiedObject = "urn:uuid:a2345678-12341234-123456789012" classificationNode = "Japan-id">
<rim:Description>
<rim:LocalizedString value = "Classifies object by /Geography/Asia/Japan node"/>
</rim:Description>
</rim:Classification>
<rim:Classification id = "classificationUsingExistingNode" classifiedObject =
"urn:uuid:a2345678-1234-1234-123456789012" classificationNode = "urn:uuid:e2345678-1234-1234123456789012">
<rim:Description>
<rim:LocalizedString value = "Classifies object using a node in the registry" />
</rim:Description>
</rim:Classification>
<rim:ObjectRef id = "urn:uuid:e2345678-1234-1234-123456789012"/>
</rim:LeafRegistryObjectList>
</SubmitObjectsRequest>
Copyright © OASIS, 2002. All Rights Reserved
Page 43 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
1391
7.4 The Update Objects Protocol
1392
1393
1394
This section describes the protocol of the Registry Service that allows a Registry Client to update
one or more existing RegistryObjects and/or repository items in the registry on behalf of a
Submitting Organization. It is expressed in UML notation as described in Appendix A.
1395
1396
Figure 13: Update Objects Sequence Diagram
1397
1398
7.4.1 UpdateObjectsRequest
1399
1400
The UpdateObjectsRequest is used by a client to update RegistryObjects and/or repository items
that already exist within the registry.
1401
Syntax:
1402
1403
1404
Figure 14: UpdateObjectsRequest Syntax
Parameters:
1405
1406
1407
1408
1409
LeafRegistryObjectsList: This parameter specifies a collection of RegistryObject
instances that are being updated within the registry. All immediate RegistryObject
children of the LeafRegistryObjectList must be a current RegistryObject already
in the registry. RegistryObjects must include all required attributes, even those the
Copyright © OASIS, 2002. All Rights Reserved
Page 44 of 188
OASIS/ebXML Registry Services Specification v3.0
1410
1411
1412
1413
1414
1415
July 2017
user does not intend to change. A missing attribute is interpreted as a request to
set that attribute to NULL or in case it has a default value, the default value will
be assumed. If this collection contains an immediate child RegistryObject that
does not already exists in the registry, then the registry must return an
InvalidRequestException. If the user wishes to submit a mix of new and updated
objects then she should use a SubmitObjectsRequest.
1416
1417
Returns:
1418
This request returns a RegistryResponse. See section 7.3.2 for details.
1419
Exceptions:
1420
In addition to the exceptions common to all requests, the following exceptions may be returned:
1421
1422
AuthorizationException: Indicates that the requestor attempted to perform an
operation for which she was not authorized.
1423
1424
ObjectNotFoundException: Indicates that the requestor referenced an object
within the request that was not found.
1425
1426
ObjectExistsException: Indicates that the requestor tried to submit an object using
an id that matched the id of an existing object in the registry.
1427
1428
InvalidRequestException: Indicates that the requestor attempted to perform an
operation which was semantically invalid.
1429
1430
UnsupportedCapabilityException: Indicates that the requestor attempted to
submit some content that is not supported by the registry.
1431
1432
QuotaExceededException: Indicates that the requestor attempted to submit more
content than the quota allowed for them by the registry.
1433
1434
7.4.2 Audit Trail
1435
1436
The RS must create AuditableEvents object with eventType Updated for each RegistryObject
updated via an UpdateObjectsRequest.
1437
7.5 The Add Slots Protocol
1438
1439
1440
This section describes the protocol of the Registry Service that allows a client to add slots to a
previously submitted RegistryObject using the LifeCycleManager. Slots provide a dynamic
mechanism for extending RegistryObjects as defined by [ebRIM].
Copyright © OASIS, 2002. All Rights Reserved
Page 45 of 188
OASIS/ebXML Registry Services Specification v3.0
1441
1442
July 2017
Figure 15: Add Slots Sequence Diagram
1443
1444
7.5.1 AddSlotsRequest
1445
The AddSlotsRequest is used by a client to add slots to an existing RegistryObject in the registry.
1446
Syntax:
1447
1448
Figure 16: AddSlotsRequest Syntax
1449
Parameters:
1450
1451
ObjectRef: This parameter specifies a reference to a RegistryObject instance to
which the requestor wishes to add slots via this request.
1452
1453
1454
Slot: This parameter specifies one or more Slot objects. Each Slot contains a
ValueList with one or more Values. Each Slot also has a slot name and a slotType
as described [ebRIM].
1455
1456
Returns:
1457
This request returns a RegistryResponse. See section 7.3.2 for details.
Copyright © OASIS, 2002. All Rights Reserved
Page 46 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
1458
Exceptions:
1459
In addition to the exceptions common to all requests, the following exceptions may be returned:
1460
1461
AuthorizationException: Indicates that the requestor attempted to perform an
operation for which she was not authorized.
1462
1463
ObjectNotFoundException: Indicates that the requestor referenced an object
within the request that was not found.
1464
1465
SlotExistsException: Indicates that the requestor tried to add a Slot using a name
that matched the name of an existing Slot in the RegistryObject.
1466
1467
InvalidRequestException: Indicates that the requestor attempted to perform an
operation which was semantically invalid.
1468
1469
7.6 The Remove Slots Protocol
1470
1471
This section describes the protocol of the Registry Service that allows a client to remove slots to
a previously submitted RegistryObject using the LifeCycleManager.
1472
1473
Figure 17: Remove Slots Sequence Diagram
1474
7.6.1 RemoveSlotsRequest
1475
1476
The RemoveSlotsRequest is used by a client to remove slots from an existing RegistryObject in
the registry.
Copyright © OASIS, 2002. All Rights Reserved
Page 47 of 188
OASIS/ebXML Registry Services Specification v3.0
1477
July 2017
Syntax:
1478
1479
Figure 18: RemoveSlotsRequest Syntax
1480
Parameters:
1481
1482
ObjectRef: This parameter specifies a reference to a RegistryObject instance
from which the requestor wishes to remove slots via this request.
1483
1484
1485
Slot: This parameter specifies one or more Slot objects. Each slot being removed
is identified by its name attribute. Any Values specified with the ValueList for the
Slot can be silently ignored.
1486
1487
Returns:
1488
This request returns a RegistryResponse. See section 7.3.2 for details.
1489
Exceptions:
1490
In addition to the exceptions common to all requests, the following exceptions may be returned:
1491
1492
AuthorizationException: Indicates that the requestor attempted to perform an
operation for which she was not authorized.
1493
1494
ObjectNotFoundException: Indicates that the requestor referenced an object
within the request that was not found.
1495
1496
SlotNotFoundException: Indicates that the requestor attempted to remove a Slot
by name where no Slot existed that matches the specified name.
1497
1498
1499
InvalidRequestException: Indicates that the requestor attempted to perform an
operation which was semantically invalid.
1500
7.7 The Approve Objects Protocol
1501
1502
This section describes the protocol of the Registry Service that allows a client to approve one or
more previously submitted RegistryObject objects using the LifeCycleManager.
Copyright © OASIS, 2002. All Rights Reserved
Page 48 of 188
OASIS/ebXML Registry Services Specification v3.0
1503
1504
July 2017
Figure 19: Approve Objects Sequence Diagram
1505
7.7.1 ApproveObjectsRequest
1506
1507
The ApproveObjectsRequest is used by a client to approve one or more existing RegistryObject
instances in the registry.
1508
Syntax:
1509
1510
Figure 20: ApproveObjectsRequest Syntax
1511
Parameters:
1512
1513
1514
ObjectRefList: This parameter specifies a collection of reference to existing
RegistryObject instances in the registry. These are the objects that the requestor
wishes to approve via this request.
1515
1516
Returns:
1517
This request returns a RegistryResponse. See section 7.3.2 for details.
1518
Exceptions:
1519
In addition to the exceptions common to all requests, the following exceptions may be returned:
1520
AuthorizationException: Indicates that the requestor attempted to perform an
Copyright © OASIS, 2002. All Rights Reserved
Page 49 of 188
OASIS/ebXML Registry Services Specification v3.0
1521
July 2017
operation for which she was not authorized.
1522
1523
ObjectNotFoundException: Indicates that the requestor referenced an object
within the request that was not found.
1524
1525
InvalidRequestException: Indicates that the requestor attempted to perform an
operation that was semantically invalid.
1526
1527
7.7.2 Audit Trail
1528
1529
The RS must create AuditableEvent objects with eventType Approved for each RegistryObject
instance approved via an ApproveObjectsRequest.
1530
7.8 The Deprecate Objects Protocol
1531
1532
1533
1534
1535
This section describes the protocol of the Registry Service that allows a client to deprecate one or
more previously submitted RegistryObject instances using the LifeCycleManager. Once a
RegistryObject is deprecated, no new references (e.g. new Associations, Classifications and
ExternalLinks) to that object can be submitted. However, existing references to a deprecated
object continue to function normally.
1536
1537
Figure 21: Deprecate Objects Sequence Diagram
1538
7.8.1 DeprecateObjectsRequest
1539
1540
The DeprecateObjectsRequest is used by a client to deprecate one or more existing
RegistryObject instances in the registry.
Copyright © OASIS, 2002. All Rights Reserved
Page 50 of 188
OASIS/ebXML Registry Services Specification v3.0
1541
July 2017
Syntax:
1542
1543
Figure 22: DeprecateObjectsRequest Syntax
1544
Parameters:
1545
1546
1547
ObjectRefList: This parameter specifies a collection of reference to existing
RegistryObject instances in the registry. These are the objects that the requestor
wishes to deprecate via this request.
1548
1549
Returns:
1550
This request returns a RegistryResponse. See section 7.3.2 for details.
1551
Exceptions:
1552
In addition to the exceptions common to all requests, the following exceptions may be returned:
1553
1554
AuthorizationException: Indicates that the requestor attempted to perform an
operation for which she was not authorized.
1555
1556
ObjectNotFoundException: Indicates that the requestor referenced an object
within the request that was not found.
1557
1558
InvalidRequestException: Indicates that the requestor attempted to perform an
operation which was semantically invalid.
1559
7.8.2 Audit Trail
1560
1561
The RS must create AuditableEvents object with eventType Deprecated for each RegistryObject
deprecated via a DeprecateObjectsRequest.
1562
7.9 The Undeprecate Objects Protocol
1563
1564
1565
1566
1567
This section describes the protocol of the Registry Service that allows a client to undo the
deprecation of one or more previously deprectaed RegistryObject instances using the
LifeCycleManager. When a RegistryObject is un-deprecated, it goes back to the Submitted status
and new references (e.g. new Associations, Classifications and ExternalLinks) to that object can
be submitted.
Copyright © OASIS, 2002. All Rights Reserved
Page 51 of 188
OASIS/ebXML Registry Services Specification v3.0
1568
1569
July 2017
Figure 23: Undeprecate Objects Sequence Diagram
1570
7.9.1 UndeprecateObjectsRequest
1571
1572
The UndeprecateObjectsRequest is used by a client to un-deprecate one or more existing
RegistryObject instances in the registry.
1573
Syntax:
1574
1575
Figure 24: UndeprecateObjectsRequest Syntax
1576
Parameters:
1577
1578
1579
1580
ObjectRefList: This parameter specifies a collection of reference to existing
RegistryObject instances in the registry. These are the objects that the requestor
wishes to un-deprecate via this request. The registry should silently ignore any
reference to a RegistryObject that is not deprecated.
1581
1582
Returns:
1583
This request returns a RegistryResponse. See section 7.3.2 for details.
1584
Exceptions:
1585
In addition to the exceptions common to all requests, the following exceptions may be returned:
1586
AuthorizationException: Indicates that the requestor attempted to perform an
Copyright © OASIS, 2002. All Rights Reserved
Page 52 of 188
OASIS/ebXML Registry Services Specification v3.0
1587
July 2017
operation for which she was not authorized.
1588
1589
ObjectNotFoundException: Indicates that the requestor referenced an object
within the request that was not found.
1590
1591
InvalidRequestException: Indicates that the requestor attempted to perform an
operation which was semantically invalid.
1592
1593
7.9.2 Audit Trail
1594
1595
The RS must create AuditableEvents object with eventType Undeprecated for each
RegistryObject undeprecated via an UndeprecateObjectsRequest.
1596
7.10 The Remove Objects Protocol
1597
1598
This section describes the protocol of the Registry Service that allows a client to remove one or
more RegistryObject instances and/or repository items using the LifeCycleManager.
1599
The remove object protocol is expressed in UML notation as described in Appendix A.
1600
1601
Figure 25: Remove Objects Sequence Diagram
1602
For details on the schema for the business documents shown in this process refer to Appendix B.
1603
7.10.1 RemoveObjectsRequest
1604
1605
The RemoveObjectsRequest is used by a client to remove one or more existing RegistryObject
and/or repository items from the registry.
Copyright © OASIS, 2002. All Rights Reserved
Page 53 of 188
OASIS/ebXML Registry Services Specification v3.0
1606
July 2017
Syntax:
1607
1608
Figure 26: RemoveObjectsRequest Syntax
1609
Parameters:
1610
1611
deletionScope: This parameter indicates the scope of impact of the
RemoveObjectsRequest. Its valid values may be as follows:
1612
1613
1614
1615
1616
DeleteRepositoryItemOnly: This deletionScope specifies that the request
should delete the repository items for the specified registry entries but not
delete the specified registry entries. This is useful in keeping references to
the registry entries valid. A registry must set the status of the
ExtrinsicObject instance to Withdrawn in this case.
1617
1618
1619
1620
1621
1622
DeleteAll: This deletionScope specifies that the request should delete both
the RegistryObject and the repository item for the specified registry
entries. Only if all references (e.g. Associations, Classifications,
ExternalLinks) to a RegistryObject have been removed, can that
RegistryObject then be removed using a RemoveObjectsRequest with
deletionScope DeleteAll.
1623
1624
1625
ObjectRefList: This parameter specifies a collection of reference to existing
RegistryObject instances in the registry. These are the objects that the requestor
wishes to remove via this request.
1626
1627
Returns:
1628
This request returns a RegistryResponse. See section 7.3.2 for details.
1629
Exceptions:
1630
In addition to the exceptions common to all requests, the following exceptions may be returned:
1631
1632
AuthorizationException: Indicates that the requestor attempted to perform an
operation for which she was not authorized.
1633
1634
ObjectNotFoundException: Indicates that the requestor referenced an object
within the request that was not found.
1635
1636
1637
1638
1639
InvalidRequestException: Indicates that the requestor attempted to perform an
operation that was semantically invalid. A specific case where this exception must
be returned is if the requestor attempts to specify deletionScope of
DeleteRepositoryItemOnly when the object is not an instance of an
ExtrinsicObject.
Copyright © OASIS, 2002. All Rights Reserved
Page 54 of 188
OASIS/ebXML Registry Services Specification v3.0
1640
1641
July 2017
ReferencesExistException: Indicates that the requestor attempted to remove a RegistryObject
while references to it still exist.
Copyright © OASIS, 2002. All Rights Reserved
Page 55 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
1642
8 Query Management Service
1643
1644
1645
1646
1647
1648
This section describes the capabilities of the Registry Service that allow a client
(QueryManagerClient) to search for or query different kinds of registry objects in the ebXML
Registry using the QueryManager interface of the Registry. The Registry supports the following
query capabilities:
Filter Query
SQL Query
1649
1650
1651
1652
The Filter Query mechanism in Section 8.2 must be supported by every Registry implementation.
The SQL Query mechanism is an optional feature and may be provided by a registry
implementation. However, if a vendor provides an SQL query capability to an ebXML Registry
it must conform to this document. As such this capability is a normative yet optional capability.
1653
1654
In a future version of this specification, the W3C XQuery syntax may be considered as another
query syntax.
1655
8.1 Ad Hoc Query Request/Response
1656
1657
1658
A client submits an ad hoc query to the QueryManager by sending an AdhocQueryRequest. The
AdhocQueryRequest contains a sub-element that defines a query in one of the supported
Registry query mechanisms.
1659
1660
1661
1662
1663
The QueryManager sends an AdhocQueryResponse either synchronously or asynchronously
back to the client. The AdhocQueryResponse returns a collection of objects whose element type
depends upon the responseOption attribute of the AdhocQueryRequest. These may be objects
representing leaf classes in [ebRIM], references to objects in the registry as well as intermediate
classes in [ebRIM] such as RegistryObject and RegistryEntry.
1664
1665
Any errors in the query request messages are indicated in the corresponding
AdhocQueryResponse message.
1666
1667
1668
Figure 27: Submit Ad Hoc Query Sequence Diagram
For details on the schema for the business documents shown in this process refer to Appendix
Copyright © OASIS, 2002. All Rights Reserved
Page 56 of 188
OASIS/ebXML Registry Services Specification v3.0
1669
A.1.
1670
8.1.1 AdhocQueryRequest
1671
The AdhocQueryRequest is used to submit queries to the registry.
1672
Syntax:
1673
1674
July 2017
Figure 28: AdhocQueryRequest Syntax
1675
Parameters:
1676
1677
federated: This optional parameter specifies that the registry must process this
query as a federated query. By default its value is false.
1678
1679
1680
1681
federation: This optional parameter specifies the id of the target Federation for a
federated query in case the registry is a member of multiplke federations. In the
absence of this parameter a registry must route the federated query to all
federations that it is a member of.
1682
FilterQuery: This parameter specifies a registry Filter Query.
1683
1684
1685
1686
1687
maxResults: This optional parameter specifies a limit on the maximum number of
results the client wishes the query to return. If unspecified, the registry should
return either all the results, or in case the result set size exceeds a registry specific
limit, the registry should return a sub-set of results that are within the bounds of
the registry specific limit. See section 0 for an illustrative example.
1688
1689
1690
ResponseOption: This required parameter allows the client to control the format
and content of the AdhocQueryResponse to this request. See section 8.1.3 for
details.
1691
SQLQuery: This parameter specifies a registry SQL Query.
1692
1693
1694
1695
startIndex: This optional integer value is used to indicate which result must be
returned as the first result when iterating over a large result set. The default
value is 0, which returns the result set starting with index 0 (first result). See
section 0 for an illustrative example.
1696
Copyright © OASIS, 2002. All Rights Reserved
Page 57 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
1697
Returns:
1698
This request returns an AdhocQueryResponse. See section 8.1.2 for details.
1699
Exceptions:
1700
In addition to the exceptions common to all requests, the following exceptions may be returned:
1701
1702
AuthorizationException: Indicates that the requestor attempted to perform an
operation for which she was not authorized.
1703
1704
InvalidQueryException: signifies that the query syntax or semantics was invalid.
Client must fix the query syntax or semantic and re-submit the query.
1705
8.1.2 AdhocQueryResponse
1706
The AdhocQueryResponse is sent by the registry as a response to AdhocQueryRequest.
1707
1708
Syntax:
1709
1710
Figure 29: AdhocQueryResponse Syntax
1711
Parameters:
1712
FilterQueryResult: This parameter specifies the result of a registry Filter Query.
1713
SQLQueryResult: This parameter specifies the result of a registry SQL Query.
1714
1715
1716
1717
startIndex: This optional integer value is used to indicate the index for the first
result in the result set returned by the query, within the complete result set
matching the query. By default, this value is 0. See section 0 for an illustrative
example.
1718
1719
1720
1721
1722
totalResultCount: This optional parameter specifies the size of the complete
result set matching the query within the registry. When this value is unspecified,
the client should assume that value is the size of the result set contained within the
result. See section 0 for an illustrative example.
1723
8.1.3 ReponseOption
1724
A client specifies an ResponseOption structure within an AdhocQueryRequest to indicate the
Copyright © OASIS, 2002. All Rights Reserved
Page 58 of 188
OASIS/ebXML Registry Services Specification v3.0
1725
July 2017
format of the results within the corresponding AdhocQueryResponse.
1726
1727
Syntax:
1728
1729
Figure 30: ResponseOption Syntax
1730
1731
Parameters:
1732
1733
1734
returnComposedObjects: This optional parameter specifies whether the
RegistryObjects returned should include composed objects as defined by Figure 1
in [ebRIM]. The default is to return all composed objects.
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
returnType: This optional enumeration parameter specifies the type of
RegistryObject to return within the response. Values for returnType are as
follows:
ObjectRef - This option specifies that the AdhocQueryResponse may contain
a collection of ObjectRef XML elements as defined in [ebRIM Schema].
Purpose of this option is to return references to registry objects.
RegistryObject - This option specifies that the AdhocQueryResponse may
contain a collection of RegistryObject XML elements as defined in [ebRIM
Schema]. In this case all attributes of the registry objects are returned
(objectType, name, description, …).
RegistryEntry - This option specifies that the AdhocQueryResponse may
contain a collection of RegistryEntry or RegistryObject XML elements as
defined in [ebRIM Schema], which correspond to RegistryEntry or
RegistryObject attributes.
LeafClass - This option specifies that the AdhocQueryResponse may contain a
collection of XML elements that correspond to leaf classes as defined in
[ebRIM Schema].
LeafClassWithRepositoryItem - This option specifies that the
AdhocQueryResponse may contain a collection of ExtrinsicObject XML
elements as defined in [ebRIM Schema] accompanied with their repository
items or RegistryEntry or RegistryObject and their attributes. Linking of
ExtrinsicObject and its repository item is accomplished using the technique
explained in Section 8.4 -Content Retrieval.
1759
1760
1761
If “returnType” specified does not match a result returned by the query, then the
registry must use the closest matching semantically valid returnType that matches
the result.
1762
1763
1764
This can be illustrated with a case when OrganizationQuery is asked to return
LeafClassWithRepositoryItem. As this is not possible, QueryManager will
assume LeafClass option instead. If OrganizationQuery is asked to retrieve a
Copyright © OASIS, 2002. All Rights Reserved
Page 59 of 188
OASIS/ebXML Registry Services Specification v3.0
1765
July 2017
RegistryEntry as a return type then RegistryObject metadata will be returned.
1766
8.1.4 Iterative Query Support
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
The iterative query feature is a normative optional feature of the registry. The
AdhocQueryRequest and AdhocQueryResponse support the ability to iterate over a large result
set matching a logical query by allowing multiple AdhocQueryRequest requests to be submitted
such that each query requests a different sliding window within the result set. This feature
enables the registry to handle queries that match a very large result set, in a scalable manner.
The iterative queries feature is not a true Cursor capability as found in databases. The registry is
not required to maintain transactional consistency or state between iterations of a query. Thus it
is possible for new objects to be added or existing objects to be removed from the complete
result set in between iterations. As a consequence it is possible to have a result set element be
skipped or duplicated between iterations.
Note that while it is not required, it may be possible for implementations to be smart and
implement a transactionally consistent iterative query feature. It is likely that a future version of
this specification will require a transactionally consistent iterative query capability.
1780
Query Iteration Example
1781
1782
1783
1784
1785
1786
Consider the case where there are 1007 Organizations in a registry. The user wishes to submit a
query that matches all 1007 Organizations. The user wishes to do the query iteratively such that
Organizations are retrieved in chunks of 100. The following table illustrates the parameters of
the AdhocQueryRequest and those of the AdhocQueryResponses for each iterative query in this
example.
AdhocQueryRequest Parameters
startIndex
maxResults
0
100
200
300
400
500
600
700
800
900
1000
100
100
100
100
100
100
100
100
100
100
100
AdhocQueryResponse Parameters
startIndex
totalResultCount
# of
Results
0
1007
100
100
1007
100
200
1007
100
300
1007
100
400
1007
100
500
1007
100
600
1007
100
700
1007
100
800
1007
100
900
1007
100
1000
1007
7
1787
1788
8.2 Filter Query Support
1789
1790
FilterQuery is an XML syntax that provides simple query capabilities for any ebXML
conforming Registry implementation. Each query alternative is directed against a single class
Copyright © OASIS, 2002. All Rights Reserved
Page 60 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
defined by the ebXML Registry Information Model (ebRIM). There are two types of filter
queries depending on which classes are queried on.
Firstly, there are RegistryObjectQuery and RegistryEntryQuery. They allow for generic
queries that might return different subclasses of the class that is queried on. The result of
such a query is a set of XML elements that correspond to instances of any class that satisfies
the responseOption defined previously in Section 8.1.3. An example might be that
RegistryObjectQuery with responseOption LeafClass will return all attributes of all instances
that satisfy the query. This implies that response might return XML elements that correspond
to classes like ClassificationScheme, RegistryPackage, Organization and Service.
Secondly, FilterQuery supports queries on selected ebRIM classes in order to define the exact
traversals of these classes. Responses to these queries are accordingly constrained.
1802
1803
1804
1805
A client submits a FilterQuery as part of an AdhocQueryRequest. The QueryManager sends an
AdhocQueryResponse back to the client, enclosing the appropriate FilterQueryResult specified
herein. The sequence diagrams for AdhocQueryRequest and AdhocQueryResponse are specified
in Section 8.1.
1806
1807
1808
1809
1810
Each FilterQuery alternative is associated with an ebRIM Binding that identifies a hierarchy of
classes derived from a single class and its associations with other classes as defined by ebRIM.
Each choice of a class pre-determines a virtual XML document that can be queried as a tree. For
example, let C be a class, let Y and Z be classes that have direct associations to C, and let V be a
class that is associated with Z. The ebRIM Binding for C might be as in Figure 31
1811
1812
Figure 31: Example ebRIM Binding
1813
1814
1815
1816
1817
1818
Label1 identifies an association from C to Y, Label2 identifies an association from C to Z, and
Label3 identifies an association from Z to V. Labels can be omitted if there is no ambiguity as to
which ebRIM association is intended. The name of the query is determined by the root class, i.e.
this is an ebRIM Binding for a CQuery. The Y node in the tree is limited to the set of Y instances
that are linked to C by the association identified by Label1. Similarly, the Z and V nodes are
limited to instances that are linked to their parent node by the identified association.
1819
1820
1821
1822
1823
Each FilterQuery alternative depends upon one or more class filters, where a class filter is a
restricted predicate clause over the attributes of a single class. Class methods that are defined in
ebRIM and that return simple types constitute “visible attributes” that are valid choices for
predicate clauses. Names of those attributes will be same as name of the corresponding method
just without the prefix ‘get’. For example, in case of “getLevelNumber” method the
Copyright © OASIS, 2002. All Rights Reserved
Page 61 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
1824
1825
1826
1827
1828
corresponding visible attribute is “levelNumber”. The supported class filters are specified in
Section 8.2.17 and the supported predicate clauses are defined in Section 8.2.18. A FilterQuery
will be composed of elements that traverse the tree to determine which branches satisfy the
designated class filters, and the query result will be the set of instances that support such a
branch.
1829
1830
1831
1832
1833
1834
1835
In the above example, the CQuery element will have three subelements, one a CFilter on the C
class to eliminate C instances that do not satisfy the predicate of the CFilter, another a YFilter on
the Y class to eliminate branches from C to Y where the target of the association does not satisfy
the YFilter, and a third to eliminate branches along a path from C through Z to V. The third
element is called a branch element because it allows class filters on each class along the path
from C to V. In general, a branch element will have subelements that are themselves class filters,
other branch elements, or a full-blown query on the class in the path.
1836
1837
1838
1839
1840
If an association from a class C to a class Y is one-to-zero or one-to-one, then at most one
branch, filter or query element on Y is allowed. However, if the association is one-to-many, then
multiple branch, filter or query elements are allowed. This allows one to specify that an instance
of C must have associations with multiple instances of Y before the instance of C is said to
satisfy the branch element.
1841
1842
1843
1844
1845
1846
1847
The FilterQuery syntax is tied to the structures defined in ebRIM. Since ebRIM is intended to be
stable, the FilterQuery syntax is stable. However, if new structures are added to the ebRIM, then
the FilterQuery syntax and semantics can be extended at the same time. Also, FilterQuery syntax
follows the inheritance hierarchy of ebRIM, which means that subclass queries inherit from their
respective superclass queries. Structures of XML elements that match the ebRIM classes are
explained in [ebRIM Schema]. Names of Filters, Queries and Branches correspond to names in
ebRIM whenever possible.
1848
1849
1850
The ebRIM Binding paragraphs in Sections 8.2.2 through 8.2.12 below identify the virtual
hierarchy for each FilterQuery alternative. The Semantic Rules for each query alternative specify
the effect of that binding on query semantics.
1851
8.2.1 FilterQuery
1852
1853
1854
1855
Purpose
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
Definition
To identify a set of queries that traverse specific registry class. Each alternative assumes a
specific binding to ebRIM. The status is a success indication or a collection of warnings and/or
exceptions.
<complexType name="FilterQueryType">
<complexContent>
<extension base="rim:AdhocQueryType">
<choice minOccurs="1" maxOccurs="1">
<element ref="tns:RegistryObjectQuery"/>
<element ref="tns:RegistryEntryQuery"/>
<element ref="tns:AssociationQuery"/>
<element ref="tns:AuditableEventQuery"/>
<element ref="tns:ClassificationQuery"/>
<element ref="tns:ClassificationNodeQuery"/>
<element ref="tns:ClassificationSchemeQuery"/>
Copyright © OASIS, 2002. All Rights Reserved
Page 62 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
<element ref="tns:RegistryPackageQuery"/>
<element ref="tns:ExtrinsicObjectQuery"/>
<element ref="tns:OrganizationQuery"/>
<element ref="tns:ServiceQuery"/>
<element ref="tns:FederationQuery"/>
<element ref="tns:RegistryQuery"/>
<element ref="tns:SubscriptionQuery"/>
<element ref="tns:UserQuery"/>
</choice>
</extension>
</complexContent>
</complexType>
<element name="FilterQuery" type="tns:FilterQueryType"/>
1905
Semantic Rules
1906
1. The semantic rules for each FilterQuery alternative are specified in subsequent subsections.
1907
1908
1909
2. Semantic rules specify the procedure for implementing the evaluation of Filter Queries.
Implementations do not necessarily have to follow the same procedure provided that the
same effect is achieved.
1910
1911
1912
3. Each FilterQueryResult is a set of XML elements to identify each instance of the result set.
Each XML attribute carries a value derived from the value of an attribute specified in the
Registry Information Model [ebRIM Schema].
1913
1914
1915
4. For each FilterQuery subelement there is only one corresponding FilterQueryResult
subelement that must be returned as a response. Class name of the FilterQueryResult
subelement has to match the class name of the FilterQuery subelement.
1916
1917
5. If a Branch or Query element for a class has no sub-elements then every persistent instance
of that class satisfies the Branch or Query.
<element name="FilterQueryResult">
<complexType>
<choice minOccurs="1" maxOccurs="1">
<element ref="tns:RegistryObjectQueryResult" />
<element ref="tns:RegistryEntryQueryResult" />
<element ref=”tns:AssociationQueryResult” />
<element ref="tns:AuditableEventQueryResult" />
<element ref=”tns:ClassificationQueryResult” />
<element ref="tns:ClassificationNodeQueryResult" />
<element ref="tns:ClassificationSchemeQueryResult" />
<element ref="tns:RegistryPackageQueryResult" />
<element ref="tns:ExtrinsicObjectQueryResult" />
<element ref="tns:OrganizationQueryResult" />
<element ref="tns:ServiceQueryResult" />
<element ref="tns:FederationQueryResult" />
<element ref="tns:RegistryQueryResult" />
<element ref="tns:SubscriptionQueryResult" />
<element ref="tns:UserQueryResult" />
</choice>
</complexType>
</element>
Copyright © OASIS, 2002. All Rights Reserved
Page 63 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
1918
1919
1920
1921
1922
6. If an error condition is raised during any part of the execution of a FilterQuery, then the
status attribute of the XML RegistryResult is set to “failure” and no AdHocQueryResult
element is returned; instead, a RegistryErrorList element must be returned with its
highestSeverity element set to “error”. At least one of the RegistryError elements in the
RegistryErrorList will have its severity attribute set to “error”.
1923
1924
1925
1926
1927
7. If no error conditions are raised during execution of a FilterQuery, then the status attribute of
the XML RegistryResult is set to “success” and an appropriate FilterQueryResult element
must be included. If a RegistryErrorList is also returned, then the highestSeverity attribute of
the RegistryErrorList is set to “warning” and the serverity attribute of each RegistryError is
set to “warning”.
1928
8.2.2 RegistryObjectQuery
1929
Purpose
1930
1931
To identify a set of registry object instances as the result of a query over selected registry
metadata.
1932
1933
ebRIM Binding
Object
Registry
1934
1935
1936
Source
1937
Auditable
Event
1938
1940
External
Identifier
1939
Name
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
Slot Value
Association
Target
Source
Classification
Scheme
Registry Object or its
subclass
Classification
Node
Registry Object or its
subclass
1945
1946
Description
Classification
1943
1944
Slot
Association
1941
1942
Target
Figure 32: ebRIM Binding for RegistryObjectQuery
Definition
<complexType name="RegistryObjectQueryType">
<sequence>
<element ref="tns:RegistryObjectFilter" minOccurs="0" maxOccurs="1" />
<element ref="tns:ExternalIdentifierFilter" minOccurs="0" maxOccurs="unbounded" />
<element ref="tns:AuditableEventQuery" minOccurs="0" maxOccurs="unbounded" />
<element ref="tns:NameBranch" minOccurs="0" maxOccurs="1" />
<element ref="tns:DescriptionBranch" minOccurs="0" maxOccurs="1" />
<element ref="tns:ClassifiedByBranch" minOccurs="0" maxOccurs="unbounded" />
<element ref="tns:SlotBranch" minOccurs="0" maxOccurs="unbounded" />
Copyright © OASIS, 2002. All Rights Reserved
Page 64 of 188
OASIS/ebXML Registry Services Specification v3.0
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
July 2017
<element ref="tns:SourceAssociationBranch" minOccurs="0" maxOccurs="unbounded" />
<element ref="tns:TargetAssociationBranch" minOccurs="0" maxOccurs="unbounded" />
</sequence>
</complexType>
<element name="RegistryObjectQuery" type="tns:RegistryObjectQueryType" />
<element name="RegistryObjectQueryResult" type="rim:RegistryObjectListType" />
<complexType name="InternationalStringBranchType">
<sequence>
<element ref="tns:LocalizedStringFilter" minOccurs="0" maxOccurs="unbounded" />
</sequence>
</complexType>
<complexType name="AssociationBranchType">
<sequence>
<element ref="tns:AssociationFilter" minOccurs="0" maxOccurs="1" />
<choice minOccurs="0" maxOccurs="1">
<element ref="tns:ExternalLinkFilter" minOccurs="0" maxOccurs="1" />
<element ref="tns:ExternalIdentifierFilter" minOccurs="0" maxOccurs="1" />
<element ref="tns:RegistryObjectQuery" minOccurs="0" maxOccurs="1" />
<element ref="tns:RegistryEntryQuery" minOccurs="0" maxOccurs="1" />
<element ref=”tns:AssociationQuery” minOccurs=”0” maxOccurs=”1” />
<element ref=”tns:ClassificationQuery” minOccurs=”0” maxOccurs=”1” />
<element ref="tns:ClassificationSchemeQuery" minOccurs="0" maxOccurs="1" />
<element ref="tns:ClassificationNodeQuery" minOccurs="0" maxOccurs="1" />
<element ref="tns:OrganizationQuery" minOccurs="0" maxOccurs="1" />
<element ref="tns:AuditableEventQuery" minOccurs="0" maxOccurs="1" />
<element ref="tns:RegistryPackageQuery" minOccurs="0" maxOccurs="1" />
<element ref="tns:ExtrinsicObjectQuery" minOccurs="0" maxOccurs="1" />
<element ref="tns:ServiceQuery" minOccurs="0" maxOccurs="1" />
<element ref="tns:FederationQuery" minOccurs="0" maxOccurs="1" />
<element ref="tns:RegistryQuery" minOccurs="0" maxOccurs="1" />
<element ref="tns:SubscriptionQuery" minOccurs="0" maxOccurs="1" />
<element ref="tns:UserQuery" minOccurs="0" maxOccurs="1" />
<element ref="tns:ServiceBindingBranch" minOccurs="0" maxOccurs="1" />
<element ref="tns:SpecificationLinkBranch" minOccurs="0" maxOccurs="1" />
</choice>
</sequence>
</complexType>
<element name="SourceAssociationBranch" type="tns:AssociationBranchType" />
<element name="TargetAssociationBranch" type="tns:AssociationBranchType" />
<element name="ClassifiedByBranch">
<complexType>
<sequence>
<element ref="tns:ClassificationFilter" minOccurs="0" maxOccurs="1" />
<element ref="tns:ClassificationSchemeQuery" minOccurs="0" maxOccurs="1" />
<element ref="tns:ClassificationNodeQuery" minOccurs="0" maxOccurs="1" />
</sequence>
</complexType>
</element>
<element name="SlotBranch">
<complexType>
<sequence>
<element ref="tns:SlotFilter" minOccurs="0" maxOccurs="1" />
Copyright © OASIS, 2002. All Rights Reserved
Page 65 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
<element ref="tns:SlotValueFilter" minOccurs="0" maxOccurs="unbounded" />
</sequence>
</complexType>
</element>
2039
Semantic Rules
2040
2041
2042
1. Let RO denote the set of all persistent RegistryObject instances in the Registry. The
following steps will eliminate instances in RO that do not satisfy the conditions of the
specified filters.
<complexType name="ServiceBindingBranchType">
<sequence>
<element ref="tns:ServiceBindingFilter" minOccurs="0" maxOccurs="1" />
<element ref="tns:SpecificationLinkBranch" minOccurs="0" maxOccurs="unbounded" />
<element ref="tns:ServiceBindingTargetBranch" minOccurs="0" maxOccurs="1" />
</sequence>
</complexType>
<element name=”ServiceBindingBranch” type=”tns:ServiceBindingBranchType” />
<element name=”ServiceBindingTargetBranch” type=”tns:ServiceBindingBranchType” />
<element name="SpecificationLinkBranch">
<complexType>
<sequence>
<element ref="tns:SpecificationLinkFilter" minOccurs="0" maxOccurs="1" />
<element ref="tns:RegistryObjectQuery" minOccurs="0" maxOccurs="1" />
<element ref="tns:RegistryEntryQuery" minOccurs="0" maxOccurs="1" />
</sequence>
</complexType>
</element>
2043
a) If RO is empty then go to number 2 below.
2044
2045
2046
b) If a RegistryObjectFilter is not specified then go to the next step; otherwise, let x be a
registry object in RO. If x does not satisfy the RegistryObjectFilter, then remove x from
RO. If RO is empty then continue to the next numbered rule.
2047
2048
2049
2050
2051
2052
2053
c) If an ExternalIdentifierFilter element is not specified, then go to the next step; otherwise,
let x be a remaining registry object in RO. If x is not linked to at least one
ExternalIdentifier instance, then remove x from RO; otherwise, treat each
ExternalIdentifierFilter element separately as follows: Let EI be the set of
ExternalIdentifier instances that satisfy the ExternalIdentifierFilter and are linked to x. If
EI is empty, then remove x from RO. If RO is empty then continue to the next numbered
rule.
2054
2055
2056
2057
d) If an AuditableEventQuery is not specified then go to the next step; otherwise, let x be a
remaining registry object in RO. If x doesn’t have an auditable event that satisfy
AuditableEventQuery as specified in Section 8.2.5 then remove x from RO. If RO is
empty then continue to the next numbered rule.
Copyright © OASIS, 2002. All Rights Reserved
Page 66 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
2058
2059
2060
2061
2062
2063
e) If a NameBranch is not specified then go to the next step; otherwise, let x be a remaining
registry object in RO. If x does not have a name then remove x from RO. If RO is empty
then continue to the next numbered rule; otherwise treat NameBranch as follows: If any
LocalizedStringFilter that is specified is not satisfied by all of the LocalizedStrings that
constitute the name of the registry object then remove x from RO. If RO is empty then
continue to the next numbered rule.
2064
2065
2066
2067
2068
2069
f) If a DescriptionBranch is not specified then go to the next step; otherwise, let x be a
remaining registry object in RO. If x does not have a description then remove x from RO.
If RO is empty then continue to the next numbered rule; otherwise treat
DescriptionBranch as follows: If any LocalizedStringFilter that is specified is not
satisfied by all of the LocalizedStrings that constitute the description of the registry
object then remove x from RO. If RO is empty then continue to the next numbered rule.
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
g) If a ClassifiedByBranch element is not specified, then go to the next step; otherwise, let x
be a remaining registry object in RO. If x is not the classifiedObject of at least one
Classification instance, then remove x from RO; otherwise, treat each
ClassifiedByBranch element separately as follows: If no ClassificationFilter is specified
within the ClassifiedByBranch, then let CL be the set of all Classification instances that
have x as the classifiedObject; otherwise, let CL be the set of Classification instances that
satisfy the ClassificationFilter and have x as the classifiedObject. If CL is empty, then
remove x from RO and continue to the next numbered rule. Otherwise, if CL is not
empty, and if a ClassificationSchemeQuery is specified, then replace CL by the set of
remaining Classification instances in CL whose defining classification scheme satisfies
the ClassificationSchemeQuery. If the new CL is empty, then remove x from RO and
continue to the next numbered rule. Otherwise, if CL remains not empty, and if a
ClassificationNodeQuery is specified, then replace CL by the set of remaining
Classification instances in CL for which a classification node exists and for which that
classification node satisfies the ClassificationNodeQuery. If the new CL is empty, then
remove x from RO. If RO is empty then continue to the next numbered rule.
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
h) If a SlotBranch element is not specified, then go to the next step; otherwise, let x be a
remaining registry object in RO. If x is not linked to at least one Slot instance, then
remove x from RO. If RO is empty then continue to the next numbered rule; otherwise,
treat each SlotBranch element separately as follows: If a SlotFilter is not specified within
the SlotBranch, then let SL be the set of all Slot instances for x; otherwise, let SL be the
set of Slot instances that satisfy the SlotFilter and are Slot instances for x. If SL is empty,
then remove x from RO and continue to the next numbered rule. Otherwise, if SL
remains not empty, and if a SlotValueFilter is specified, replace SL by the set of
remaining Slot instances in SL for which every specified SlotValueFilter is valid. If SL is
empty, then remove x from RO. If RO is empty then continue to the next numbered rule.
2096
2097
2098
2099
2100
i) If a SourceAssociationBranch element is not specified then go to the next step; otherwise,
let x be a remaining registry object in RO. If x is not the source object of at least one
Association instance, then remove x from RO. If RO is empty then continue to the next
numbered rule; otherwise, treat each SourceAssociationBranch element separately as
follows:
Copyright © OASIS, 2002. All Rights Reserved
Page 67 of 188
OASIS/ebXML Registry Services Specification v3.0
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
July 2017
If no AssociationFilter is specified within the SourceAssociationBranch, then let AF be
the set of all Association instances that have x as a source object; otherwise, let AF be the
set of Association instances that satisfy the AssociationFilter and have x as the source
object. If AF is empty, then remove x from RO.
If RO is empty then continue to the next numbered rule.
If an ExternalLinkFilter is specified within the SourceAssociationBranch, then let ROT
be the set of ExternalLink instances that satisfy the ExternalLinkFilter and are the target
object of some element of AF. If ROT is empty, then remove x from RO. If RO is empty
then continue to the next numbered rule.
If an ExternalIdentifierFilter is specified within the SourceAssociationBranch, then let
ROT be the set of ExternalIdentifier instances that satisfy the ExternalIdentifierFilter and
are the target object of some element of AF. If ROT is empty, then remove x from RO. If
RO is empty then continue to the next numbered rule.
If a RegistryObjectQuery is specified within the SourceAssociationBranch, then let ROT
be the set of RegistryObject instances that satisfy the RegistryObjectQuery and are the
target object of some element of AF. If ROT is empty, then remove x from RO. If RO is
empty then continue to the next numbered rule.
If a RegistryEntryQuery is specified within the SourceAssociationBranch, then let ROT
be the set of RegistryEntry instances that satisfy the RegistryEntryQuery and are the
target object of some element of AF. If ROT is empty, then remove x from RO. If RO is
empty then continue to the next numbered rule.
If a ClassificationSchemeQuery is specified within the SourceAssociationBranch, then let
ROT be the set of ClassificationScheme instances that satisfy the
ClassificationSchemeQuery and are the target object of some element of AF. If ROT is
empty, then remove x from RO. If RO is empty then continue to the next numbered rule.
If a ClassificationNodeQuery is specified within the SourceAssociationBranch, then let
ROT be the set of ClassificationNode instances that satisfy the ClassificationNodeQuery
and are the target object of some element of AF. If ROT is empty, then remove x from
RO. If RO is empty then continue to the next numbered rule.
If an OrganizationQuery is specified within the SourceAssociationBranch, then let ROT
be the set of Organization instances that satisfy the OrganizationQuery and are the target
object of some element of AF. If ROT is empty, then remove x from RO. If RO is empty
then continue to the next numbered rule.
Copyright © OASIS, 2002. All Rights Reserved
Page 68 of 188
OASIS/ebXML Registry Services Specification v3.0
2143
2144
2145
2146
2147
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
July 2017
If an AuditableEventQuery is specified within the SourceAssociationBranch, then let
ROT be the set of AuditableEvent instances that satisfy the AuditableEventQuery and are
the target object of some element of AF. If ROT is empty, then remove x from RO. If RO
is empty then continue to the next numbered rule.
If a RegistryPackageQuery is specified within the SourceAssociationBranch, then let
ROT be the set of RegistryPackage instances that satisfy the RegistryPackageQuery and
are the target object of some element of AF. If ROT is empty, then remove x from RO. If
RO is empty then continue to the next numbered rule.
If an ExtrinsicObjectQuery is specified within the SourceAssociationBranch, then let
ROT be the set of ExtrinsicObject instances that satisfy the ExtrinsicObjectQuery and are
the target object of some element of AF. If ROT is empty, then remove x from RO. If RO
is empty then continue to the next numbered rule.
If a ServiceQuery is specified within the SourceAssociationBranch, then let ROT be the
set of Service instances that satisfy the ServiceQuery and are the target object of some
element of AF. If ROT is empty, then remove x from RO. If RO is empty then continue
to the next numbered rule.
If a ClassificationQuery is specified within the SourceAssociationBranch, then let ROT
be the set of Classification instances that satisfy the ClassificationQuery and are the
target object of some element of AF. If ROT is empty, then remove x from RO. If RO is
empty then continue to the next numbered rule (Rule 2).
If a ServiceBindingBranch is specified within the SourceAssociationBranch, then let
ROT be the set of ServiceBinding instances that are the target object of some element of
AF. If ROT is empty, then remove x from RO. If RO is empty then continue to the next
numbered rule. Let sb be the member of ROT. If a ServiceBindingFilter element is
specified within the ServiceBindingBranch, and if sb does not satisfy that filter, then
remove sb from ROT. If ROT is empty then remove x from RO. If RO is empty then
continue to the next numbered rule. If a SpecificationLinkBranch is specified within the
ServiceBindingBranch then consider each SpecificationLinkBranch element separately as
follows:
Let sb be a remaining service binding in ROT. Let SL be the set of all specification link
instances sl that describe specification links of sb. If a SpecificationLinkFilter element is
specified within the SpecificationLinkBranch, and if sl does not satisfy that filter, then
remove sl from SL. If SL is empty then remove sb from ROT. If ROT is empty then
remove x from RO. If RO is empty then continue to the next numbered rule. If a
RegistryObjectQuery element is specified within the SpecificationLinkBranch then let sl
be a remaining specification link in SL. Treat RegistryObjectQuery element as follows:
Let RO be the result set of the RegistryObjectQuery as defined in Section 8.2.2. If sl is
not a specification link for at least one registry object in RO, then remove sl from SL. If
SL is empty then remove sb from ROT. If ROT is empty then remove x from RO. If RO
is empty then continue to the next numbered rule. If a RegistryEntryQuery element is
Copyright © OASIS, 2002. All Rights Reserved
Page 69 of 188
OASIS/ebXML Registry Services Specification v3.0
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
July 2017
specified within the SpecificationLinkBranch then let sl be a remaining specification link
in SL. Treat RegistryEntryQuery element as follows: Let RE be the result set of the
RegistryEntryQuery as defined in Section 8.2.3. If sl is not a specification link for at least
one registry entry in RE, then remove sl from SL. If SL is empty then remove sb from
ROT. If ROT is empty then remove x from RO. If RO is empty then continue to the next
numbered rule. If a ServiceBindingTargetBranch is specified within the
ServiceBindingBranch, then let SBT be the set of ServiceBinding instances that satisfy
the ServiceBindingTargetBranch and are the target service binding of some element of
ROT. If SBT is empty then remove sb from ROT. If ROT is empty, then remove x from
RO. If RO is empty then continue to the next numbered rule.
If a SpecificationLinkBranch is specified within the SourceAssociationBranch, then let
ROT be the set of SpecificationLink instances that are the target object of some element
of AF. If ROT is empty, then remove x from RO. If RO is empty then continue to the
next numbered rule. Let sl be the member of ROT. If a SpecificationLinkFilter element is
specified within the SpecificationLinkBranch, and if sl does not satisfy that filter, then
remove sl from ROT. If ROT is empty then remove x from RO. If RO is empty then
continue to the next numbered rule. If a RegistryObjectQuery element is specified within
the SpecificationLinkBranch then let sl be a remaining specification link in ROT. Treat
RegistryObjectQuery element as follows: Let RO be the result set of the
RegistryObjectQuery as defined in Section 8.2.2. If sl is not a specification link for some
registry object in RO, then remove sl from ROT. If ROT is empty then remove x from
RO. If RO is empty then continue to the next numbered rule. If a RegistryEntryQuery
element is specified within the SpecificationLinkBranch then let sl be a remaining
specification link in ROT. Treat RegistryEntryQuery element as follows: Let RE be the
result set of the RegistryEntryQuery as defined in Section 8.2.3. If sl is not a specification
link for at least one registry entry in RE, then remove sl from ROT. If ROT is empty then
remove x from RO. If RO is empty then continue to the next numbered rule.
If an AssociationQuery is specified within the SourceAssociationBranch, then let ROT be
the set of Association instances that satisfy the AssociationQuery and are the target object
of some element of AF. If ROT is empty, then remove x from RO. If RO is empty then
continue to the next numbered rule (Rule 2).
If a Federation Query is specified within the SourceAssociationBranch, then let ROS be
the set of Federation instances that satisfy the FederationQuery and are the source object
of some element of AF. If ROS is empty, then remove x from RO. If RO is empty then
continue to the next numbered rule.
If a RegistryQuery is specified within the SourceAssociationBranch, then let ROS be the
set of Registry instances that satisfy the RegistryQuery and are the source object of some
element of AF. If ROS is empty, then remove x from RO. If RO is empty then continue
to the next numbered rule.
Copyright © OASIS, 2002. All Rights Reserved
Page 70 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
If a SubscriptionQuery is specified within the SourceAssociationBranch, then let ROS be
the set of Subscription instances that satisfy the SubscriptionQuery and are the source
object of some element of AF. If ROS is empty, then remove x from RO. If RO is empty
then continue to the next numbered rule.
2243
2244
2245
2246
2247
2248
2249
2250
2251
2252
2253
2254
2255
2256
2257
2258
2259
2260
2261
2262
2263
2264
2265
2266
2267
2268
2269
2270
2271
2272
2273
2274
2275
j) If a TargetAssociationBranch element is not specified then go to the next step; otherwise,
let x be a remaining registry object in RO. If x is not the target object of some
Association instance, then remove x from RO. If RO is empty then continue to the next
numbered rule; otherwise, treat each TargetAssociationBranch element separately as
follows:
If a UserQuery is specified within the SourceAssociationBranch, then let ROS be the set
of User instances that satisfy the UserQuery and are the source object of some element of
AF. If ROS is empty, then remove x from RO. If RO is empty then continue to the next
numbered rule.
If no AssociationFilter is specified within the TargetAssociationBranch, then let AF be
the set of all Association instances that have x as a target object; otherwise, let AF be the
set of Association instances that satisfy the AssociationFilter and have x as the target
object. If AF is empty, then remove x from RO. If RO is empty then continue to the next
numbered rule.
If an ExternalLinkFilter is specified within the TargetAssociationBranch, then let ROS be
the set of ExternalLink instances that satisfy the ExternalLinkFilter and are the source
object of some element of AF. If ROS is empty, then remove x from RO. If RO is empty
then continue to the next numbered rule.
If an ExternalIdentifierFilter is specified within the TargetAssociationBranch, then let
ROS be the set of ExternalIdentifier instances that satisfy the ExternalIdentifierFilter and
are the source object of some element of AF. If ROS is empty, then remove x from RO. If
RO is empty then continue to the next numbered rule.
If a RegistryObjectQuery is specified within the TargetAssociationBranch, then let ROS
be the set of RegistryObject instances that satisfy the RegistryObjectQuery and are the
source object of some element of AF. If ROS is empty, then remove x from RO. If RO is
empty then continue to the next numbered rule.
If a RegistryEntryQuery is specified within the TargetAssociationBranch, then let ROS
be the set of
RegistryEntry instances that satisfy the RegistryEntryQuery and are the source object of
some element of AF. If ROS is empty, then remove x from RO. If RO is empty then
continue to the next numbered rule.
Copyright © OASIS, 2002. All Rights Reserved
Page 71 of 188
OASIS/ebXML Registry Services Specification v3.0
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
2313
2314
2315
July 2017
If a ClassificationSchemeQuery is specified within the TargetAssociationBranch, then let
ROS be the set of ClassificationScheme instances that satisfy the
ClassificationSchemeQuery and are the source object of some element of AF. If ROS is
empty, then remove x from RO. If RO is empty then continue to the next numbered rule.
If a ClassificationNodeQuery is specified within the TargetAssociationBranch, then let
ROS be the set of ClassificationNode instances that satisfy the ClassificationNodeQuery
and are the source object of some element of AF. If ROS is empty, then remove x from
RO. If RO is empty then continue to the next numbered rule.
If an OrganizationQuery is specified within the TargetAssociationBranch, then let ROS
be the set of Organization instances that satisfy the OrganizationQuery and are the source
object of some element of AF. If ROS is empty, then remove x from RO. If RO is empty
then continue to the next numbered rule.
If an AuditableEventQuery is specified within the TargetAssociationBranch, then let
ROS be the set of AuditableEvent instances that satisfy the AuditableEventQuery and are
the source object of some element of AF. If ROS is empty, then remove x from RO. If
RO is empty then continue to the next numbered rule.
If a RegistryPackageQuery is specified within the TargetAssociationBranch, then let
ROS be the set of RegistryPackage instances that satisfy the RegistryPackageQuery and
are the source object of some element of AF. If ROS is empty, then remove x from RO. If
RO is empty then continue to the next numbered rule.
If an ExtrinsicObjectQuery is specified within the TargetAssociationBranch, then let
ROS be the set of ExtrinsicObject instances that satisfy the ExtrinsicObjectQuery and are
the source object of some element of AF. If ROS is empty, then remove x from RO. If
RO is empty then continue to the next numbered rule.
If a ServiceQuery is specified within the TargetAssociationBranch, then let ROS be the
set of Service instances that satisfy the ServiceQuery and are the source object of some
element of AF. If ROS is empty, then remove x from RO. If RO is empty then continue
to the next numbered rule.
If a ClassificationQuery is specified within the TargetAssociationBranch, then let ROS be
the set of Classification instances that satisfy the ClassificationQuery and are the source
object of some element of AF. If ROS is empty, then remove x from RO. If RO is empty
then continue to the next numbered rule (Rule 2).
Copyright © OASIS, 2002. All Rights Reserved
Page 72 of 188
OASIS/ebXML Registry Services Specification v3.0
2316
2317
2318
2319
2320
2321
2322
2323
2324
2325
2326
2327
2328
2329
2330
2331
2332
2333
2334
2335
2336
2337
2338
2339
2340
2341
2342
July 2017
If a ServiceBindingBranch is specified within the TargetAssociationBranch, then let ROS
be the set of ServiceBinding instances that are the source object of some element of AF.
If ROS is empty, then remove x from RO. If RO is empty then continue to the next
numbered rule. Let sb be the member of ROS. If a ServiceBindingFilter element is
specified within the ServiceBindingBranch, and if sb does not satisfy that filter, then
remove sb from ROS. If ROS is empty then remove x from RO. If RO is empty then
continue to the next numbered rule. If a SpecificationLinkBranch is specified within the
ServiceBindingBranch then consider each SpecificationLinkBranch element separately as
follows:
Let sb be a remaining service binding in ROS. Let SL be the set of all specification link
instances sl that describe specification links of sb. If a SpecificationLinkFilter element is
specified within the SpecificationLinkBranch, and if sl does not satisfy that filter, then
remove sl from SL. If SL is empty then remove sb from ROS. If ROS is empty then
remove x from RO. If RO is empty then continue to the next numbered rule. If a
RegistryObjectQuery element is specified within the SpecificationLinkBranch then let sl
be a remaining specification link in SL. Treat RegistryObjectQuery element as follows:
Let RO be the result set of the RegistryObjectQuery as defined in Section 8.2.2. If sl is
not a specification link for some registry object in RO, then remove sl from SL. If SL is
empty then remove sb from ROS. If ROS is empty then remove x from RO. If RO is
empty then continue to the next numbered rule. If a RegistryEntryQuery element is
specified within the SpecificationLinkBranch then let sl be a remaining specification link
in SL. Treat RegistryEntryQuery element as follows: Let RE be the result set of the
RegistryEntryQuery as defined in Section 8.2.3. If sl is not a specification link for some
registry entry in RE, then remove sl from SL. If SL is empty then remove sb from ROS.
If ROS is empty then remove x from RO. If RO is empty then continue to the next
numbered rule.
Copyright © OASIS, 2002. All Rights Reserved
Page 73 of 188
OASIS/ebXML Registry Services Specification v3.0
2343
2344
2345
2346
2347
2348
2349
2350
2351
2352
2353
2354
2355
2356
2357
2358
2359
2360
2361
2362
2363
2364
2365
2366
2367
2368
2369
2370
2371
2372
2373
2374
2375
2376
2377
2378
2379
2380
2381
2382
2383
2384
2385
July 2017
If a SpecificationLinkBranch is specified within the TargetAssociationBranch, then let
ROS be the set of SpecificationLink instances that are the source object of some element
of AF. If ROS is empty, then remove x from RO. If RO is empty then continue to the
next numbered rule. Let sl be the member of ROS. If a SpecificationLinkFilter element is
specified within the SpecificationLinkBranch, and if sl does not satisfy that filter, then
remove sl from ROS. If ROS is empty then remove x from RO. If RO is empty then
continue to the next numbered rule. If a RegistryObjectQuery element is specified within
the SpecificationLinkBranch then let sl be a remaining specification link in ROS. Treat
RegistryObjectQuery element as follows: Let RO be the result set of the
RegistryObjectQuery as defined in Section 8.2.2. If sl is not a specification link for some
registry object in RO, then remove sl from ROS. If ROS is empty then remove x from
RO. If RO is empty then continue to the next numbered rule. If a RegistryEntryQuery
element is specified within the SpecificationLinkBranch then let sl be a remaining
specification link in ROS. Treat RegistryEntryQuery element as follows: Let RE be the
result set of the RegistryEntryQuery as defined in Section 8.2.3. If sl is not a specification
link for some registry entry in RE, then remove sl from ROS. If ROS is empty then
remove x from RO. If RO is empty then continue to the next numbered rule. If a
ServiceBindingTargetBranch is specified within the ServiceBindingBranch, then let SBT
be the set of ServiceBinding instances that satisfy the ServiceBindingTargetBranch and
are the target service binding of some element of ROT. If SBT is empty then remove sb
from ROT. If ROT is empty, then remove x from RO. If RO is empty then continue to the
next numbered rule.
If an AssociationQuery is specified within the TargetAssociationBranch, then let ROS be
the set of Association instances that satisfy the AssociationQuery and are the source
object of some element of AF. If ROS is empty, then remove x from RO. If RO is empty
then continue to the next numbered rule (Rule 2).
If a Federation Query is specified within the TargetAssociationBranch, then let ROS be
the set of Federation instances that satisfy the FederationQuery and are the source object
of some element of AF. If ROS is empty, then remove x from RO. If RO is empty then
continue to the next numbered rule.
If a RegistryQuery is specified within the TargetAssociationBranch, then let ROS be the
set of Registry instances that satisfy the RegistryQuery and are the source object of some
element of AF. If ROS is empty, then remove x from RO. If RO is empty then continue
to the next numbered rule.
If a SubscriptionQuery is specified within the TargetAssociationBranch, then let ROS be
the set of Subscription instances that satisfy the SubscriptionQuery and are the source
object of some element of AF. If ROS is empty, then remove x from RO. If RO is empty
then continue to the next numbered rule.
Copyright © OASIS, 2002. All Rights Reserved
Page 74 of 188
OASIS/ebXML Registry Services Specification v3.0
2386
2387
2388
2389
July 2017
If a UserQuery is specified within the TargetAssociationBranch, then let ROS be the set
of User instances that satisfy the UserQuery and are the source object of some element of
AF. If ROS is empty, then remove x from RO. If RO is empty then continue to the next
numbered rule.
2390
2391
2.
If RO is empty, then raise the warning: registry object query result is empty; otherwise, set
RO to be the result of the RegistryObjectQuery.
2392
2393
3.
Return the result and any accumulated warnings or exceptions (in the RegistryErrorList)
within the RegistryResponse.
2394
Examples
2395
2396
2397
2398
2399
2400
2401
2402
2403
2404
2405
2406
2407
2408
2409
2410
2411
2412
2413
2414
2415
2416
2417
2418
2419
2420
2421
2422
2423
2424
2425
2426
2427
2428
2429
2430
2431
2432
2433
2434
2435
2436
2437
A client application needs all items that are classified by two different classification schemes,
one based on "Industry" and another based on "Geography". Both schemes have been defined by
ebXML and are registered as "urn:ebxml:cs:industry" and "urn:ebxml:cs:geography",
respectively. The following query identifies registry entries for all registered items that are
classified by Industry as any subnode of "Automotive" and by Geography as any subnode of
"Asia/Japan".
<AdhocQueryRequest>
<ResponseOption returnType = "RegistryEntry"/>
<FilterQuery>
<RegistryObjectQuery>
<ClassifiedByBranch>
<ClassificationFilter>
<Clause>
<SimpleClause leftArgument = "path">
<StringClause stringPredicate = "Equal">//Automotive</StringClause>
</SimpleClause>
</Clause>
</ClassificationFilter>
<ClassificationSchemeQuery>
<NameBranch>
<LocalizedStringFilter>
<Clause>
<SimpleClause leftArgument = "value">
<StringClause stringPredicate = "Equal">urn:ebxml:cs:industry</StringClause>
</SimpleClause>
</Clause>
</LocalizedStringFilter>
</NameBranch>
</ClassificationSchemeQuery>
</ClassifiedByBranch>
<ClassifiedByBranch>
<ClassificationFilter>
<Clause>
<SimpleClause leftArgument = "path">
<StringClause stringPredicate = "StartsWith">/Geography-id/Asia/Japan</StringClause>
</SimpleClause>
</Clause>
</ClassificationFilter>
<ClassificationSchemeQuery>
<NameBranch>
<LocalizedStringFilter>
<Clause>
Copyright © OASIS, 2002. All Rights Reserved
Page 75 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
2438
2439
2440
2441
2442
2443
2444
2445
2446
2447
2448
2449
<SimpleClause leftArgument = "value">
<StringClause stringPredicate = "Equal">urn:ebxml:cs:geography</StringClause>
</SimpleClause>
</Clause>
</LocalizedStringFilter>
</NameBranch>
</ClassificationSchemeQuery>
</ClassifiedByBranch>
</RegistryObjectQuery>
</FilterQuery>
</AdhocQueryRequest>
2450
2451
2452
2453
2454
2455
2456
2457
2458
2459
2460
2461
2462
2463
2464
2465
2466
2467
2468
2469
2470
2471
2472
2473
2474
2475
2476
2477
A client application wishes to identify all RegistryObject instances that are classified by some
internal classification scheme and have some given keyword as part of the description of one of
the classification nodes of that classification scheme. The following query identifies all such
RegistryObject instances. The query takes advantage of the knowledge that the classification
scheme is internal, and thus that all of its nodes are fully described as ClassificationNode
instances.
2478
8.2.3 RegistryEntryQuery
2479
Purpose
2480
2481
To identify a set of registry entry instances as the result of a query over selected registry
metadata.
2482
2483
ebRIM Binding
<AdhocQueryRequest>
<ResponseOption returnType = "RegistryObject"/>
<FilterQuery>
<RegistryObjectQuery>
<ClassifiedByBranch>
<ClassificationNodeQuery>
<DescriptionBranch>
<LocalizedStringFilter>
<Clause>
<SimpleClause leftArgument = "value">
<StringClause stringPredicate = "Equal">transistor</StringClause>
</SimpleClause>
</Clause>
</LocalizedStringFilter>
</DescriptionBranch>
</ClassificationNodeQuery>
</ClassifiedByBranch>
</RegistryObjectQuery>
</FilterQuery>
</AdhocQueryRequest>
Copyright © OASIS, 2002. All Rights Reserved
Page 76 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
Registry Entry
Registry
Object
Figure 33: ebRIM Binding for RegistryEntryQuery
2484
2485
2486
2487
2488
2489
2490
2491
2492
2493
2494
2495
2496
2497
2498
2499
2500
2501
2502
2503
2504
2505
2506
2507
2508
2509
2510
2511
2512
2513
Definition
2514
Semantic Rules
2515
2516
1. Let RE denote the set of all persistent RegistryEntry instances in the Registry. The following
steps will eliminate instances in RE that do not satisfy the conditions of the specified filters.
<complexType name="RegistryEntryQueryType">
<complexContent>
<extension base="tns:RegistryObjectQueryType">
<sequence>
<element ref="tns:RegistryEntryFilter" minOccurs="0" maxOccurs="1" />
</sequence>
</extension>
</complexContent>
</complexType>
<element name="RegistryEntryQuery" type="tns:RegistryEntryQueryType" />
<element name="RegistryEntryQueryResult">
<complexType>
<choice minOccurs="0" maxOccurs="unbounded">
<element ref="rim:ObjectRef" />
<element ref="rim:ClassificationScheme" />
<element ref="rim:ExtrinsicObject" />
<element ref="rim:RegistryEntry" />
<element ref="rim:RegistryObject" />
<element ref="rim:RegistryPackage" />
<element ref="rim:Service" />
<element ref="rim:Federation" />
<element ref="rim:Registry" />
</choice>
</complexType>
</element>
2517
a) If RE is empty then continue to the next numbered rule.
2518
2519
2520
b) If a RegistryEntryFilter is not specified then go to the next step; otherwise, let x be a
registry entry in RE. If x does not satisfy the RegistryEntryFilter, then remove x from RE.
If RE is empty then continue to the next numbered rule.
2521
2522
c) Let RE be the set of remaining RegistryEntry instances. Evaluate inherited
RegistryObjectQuery over RE as explained in Section 8.2.2.
2523
2524
2. If RE is empty, then raise the warning: registry entry query result is empty; otherwise, set RE
to be the result of the RegistryEntryQuery.
Copyright © OASIS, 2002. All Rights Reserved
Page 77 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
2525
2526
3. Return the result and any accumulated warnings or exceptions (in the RegistryErrorList)
within the RegistryResponse.
2527
Examples
2528
2529
2530
2531
2532
2533
2534
2535
2536
2537
2538
2539
2540
2541
2542
2543
2544
2545
2546
2547
2548
2549
2550
2551
2552
2553
2554
2555
2556
2557
2558
2559
2560
2561
2562
2563
2564
2565
2566
2567
2568
A client wishes to establish a trading relationship with XYZ Corporation and wants to know if
they have registered any of their business documents in the Registry. The following query
returns a set of registry entry identifiers for currently registered items submitted by any
organization whose name includes the string "XYZ". It does not return any registry entry
identifiers for superseded, replaced, deprecated, or withdrawn items.
2569
2570
2571
2572
2573
2574
2575
2576
A client is using the United Nations Standard Product and Services Classification (UNSPSC)
scheme and wants to identify all companies that deal with products classified as "Integrated
circuit components", i.e. UNSPSC code "321118". The client knows that companies have
registered their Collaboration Protocol Profile (CPP) documents in the Registry, and that each
such profile has been classified by UNSPSC according to the products the company deals with.
However, the client does not know if the UNSPSC classification scheme is internal or external to
this registry. The following query returns a set of approved registry entry instances for CPP’s of
companies that deal with integrated circuit components.
<AdhocQueryRequest>
<ResponseOption returnType = "ObjectRef"/>
<FilterQuery>
<RegistryEntryQuery>
<TargetAssociationBranch>
<AssociationFilter>
<Clause>
<SimpleClause leftArgument = "associationType">
<StringClause stringPredicate = "Equal">SubmitterOf</StringClause>
</SimpleClause>
</Clause>
</AssociationFilter>
<OrganizationQuery>
<NameBranch>
<LocalizedStringFilter>
<Clause>
<SimpleClause leftArgument = "value">
<StringClause stringPredicate = "Contains">XYZ</StringClause>
</SimpleClause>
</Clause>
</LocalizedStringFilter>
</NameBranch>
</OrganizationQuery>
</TargetAssociationBranch>
<RegistryEntryFilter>
<Clause>
<SimpleClause leftArgument = "status">
<StringClause stringPredicate = "Equal">Approved</StringClause>
</SimpleClause>
</Clause>
</RegistryEntryFilter>
</RegistryEntryQuery>
</FilterQuery>
</AdhocQueryRequest>
Copyright © OASIS, 2002. All Rights Reserved
Page 78 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
2577
2578
2579
2580
2581
2582
2583
2584
2585
2586
2587
2588
2589
2590
2591
2592
2593
2594
2595
2596
2597
2598
2599
2600
2601
2602
2603
2604
2605
2606
2607
2608
2609
2610
2611
2612
2613
2614
2615
2616
2617
2618
2619
2620
2621
<AdhocQueryRequest>
<ResponseOption returnType = "RegistryEntry"/>
<FilterQuery>
<RegistryEntryQuery>
<ClassifiedByBranch>
<ClassificationFilter>
<Clause>
<SimpleClause leftArgument = "nodeRepresentation">
<StringClause stringPredicate = "Equal">321118</StringClause>
</SimpleClause>
</Clause>
</ClassificationFilter>
<ClassificationSchemeQuery>
<NameBranch>
<LocalizedStringFilter>
<Clause>
<SimpleClause leftArgument = "value">
<StringClause stringPredicate = "Equal">urn:org:un:spsc:cs2001</StringClause>
</SimpleClause>
</Clause>
</LocalizedStringFilter>
</NameBranch>
</ClassificationSchemeQuery>
</ClassifiedByBranch>
<RegistryEntryFilter>
<Clause>
<CompoundClause connectivePredicate = "And">
<Clause>
<SimpleClause leftArgument = "objectType">
<StringClause stringPredicate = "Equal">CPP</StringClause>
</SimpleClause>
</Clause>
<Clause>
<SimpleClause leftArgument = "status">
<StringClause stringPredicate = "Equal">Approved</StringClause>
</SimpleClause>
</Clause>
</CompoundClause>
</Clause>
</RegistryEntryFilter>
</RegistryEntryQuery>
</FilterQuery>
</AdhocQueryRequest>
2622
8.2.4 AssociationQuery
2623
Purpose
2624
To identify a set of association instances as the result of a query over selected registry metadata.
2625
2626
ebRIM Binding
Copyright © OASIS, 2002. All Rights Reserved
Page 79 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
Association
Registry
Object
Figure 34: ebRIM Binding for AssociationQuery
2627
2628
2629
2630
2631
2632
2633
2634
2635
2636
2637
2638
2639
2640
2641
2642
2643
2644
2645
2646
2647
2648
2649
2650
Definition
2651
Semantic Rules
2652
2653
1. Let A denote the set of all persistent Association instances in the Registry. The following
steps will eliminate instances in A that do not satisfy the conditions of the specified filters.
<complexType name = "AssociationQueryType">
<complexContent>
<extension base = "tns:RegistryObjectQueryType">
<sequence>
<element ref = "tns:AssociationFilter" minOccurs = "0" maxOccurs = "1"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name = "AssociationQuery" type = "tns:AssociationQueryType"/>
<element name="AssociationQueryResult">
<complexType>
<choice minOccurs="0" maxOccurs="unbounded">
<element ref="rim:ObjectRef" />
<element ref="rim:RegistryObject" />
<element ref="rim:Association" />
</choice>
</complexType>
</element>
2654
a) If A is empty then continue to the next numbered rule.
2655
2656
2657
2658
b) If an AssociationFilter element is not directly contained in the AssociationQuery element,
then go to the next step; otherwise let x be an association instance in A. If x does not
satisfy the AssociationFilter then remove x from A. If A is empty then continue to the
next numbered rule.
2659
2660
c) Let A be the set of remaining Association instances. Evaluate inherited
RegistryObjectQuery over A as explained in Section 8.2.2.
2661
2662
2. If A is empty, then raise the warning: association query result is empty; otherwise, set A to
be the result of the AssociationQuery.
2663
2664
3. Return the result and any accumulated warnings or exceptions (in the RegistryErrorList)
within the RegistryResponse.
2665
Examples
2666
2667
A client application wishes to identify a set of associations that are ‘equivalentTo’ a set of other
associations.
Copyright © OASIS, 2002. All Rights Reserved
Page 80 of 188
OASIS/ebXML Registry Services Specification v3.0
2668
2669
2670
2671
2672
2673
2674
2675
2676
2677
2678
2679
2680
2681
2682
2683
2684
2685
2686
2687
2688
2689
2690
2691
2692
2693
2694
2695
2696
2697
2698
2699
2700
2701
July 2017
<AdhocQueryRequest">
<ResponseOption returnType="LeafClass" />
<FilterQuery>
<AssociationQuery>
<SourceAssociationBranch>
<AssociationFilter>
<Clause>
<SimpleClause leftArgument="associationType">
<StringClause stringPredicate="Equal">EquivalentTo</StringClause>
</SimpleClause>
</Clause>
</AssociationFilter>
<AssociationQuery>
<AssociationFilter>
<Clause>
<SimpleClause leftArgument="associationType">
<StringClause stringPredicate="StartsWith">Sin</StringClause>
</SimpleClause>
</Clause>
</AssociationFilter>
</AssociationQuery>
</SourceAssociationBranch>
<AssociationFilter>
<Clause>
<SimpleClause leftArgument="associationType">
<StringClause stringPredicate="StartsWith">Son</StringClause>
</SimpleClause>
</Clause>
</AssociationFilter>
</AssociationQuery>
</FilterQuery>
</AdhocQueryRequest>
Copyright © OASIS, 2002. All Rights Reserved
Page 81 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
2702
2703
8.2.5 AuditableEventQuery
2704
Purpose
2705
2706
To identify a set of auditable event instances as the result of a query over selected registry
metadata.
2707
2708
ebRIM Binding
2709
Auditable Event
2710
Registry
Object
2711
2712
2713
Registry
Object
2714
2715
Person
Name
Address
2716
2717
Postal Address
Telephone
Number
Email Address
2718
Figure 35: ebRIM Binding for AuditableEventQuery
2719
2720
2721
2722
2723
2724
2725
2726
2727
2728
2729
2730
2731
2732
2733
2734
2735
2736
2737
2738
2739
2740
2741
2742
2743
2744
Registry
Entry
User
Definition
<complexType name="AuditableEventQueryType">
<complexContent>
<extension base="tns:RegistryObjectQueryType">
<sequence>
<element ref="tns:AuditableEventFilter" minOccurs="0" />
<element ref="tns:RegistryObjectQuery" minOccurs="0" maxOccurs="unbounded" />
<element ref="tns:RegistryEntryQuery" minOccurs="0" maxOccurs="unbounded" />
<element ref="tns:UserQuery" minOccurs="0" maxOccurs="1" />
</sequence>
</extension>
</complexContent>
</complexType>
<element name="AuditableEventQuery" type="tns:AuditableEventQueryType" />
<element name="AuditableEventQueryResult">
<complexType>
<choice minOccurs="0" maxOccurs="unbounded">
<element ref="rim:ObjectRef" />
<element ref="rim:RegistryObject" />
<element ref="rim:AuditableEvent" />
</choice>
</complexType>
</element>
Copyright © OASIS, 2002. All Rights Reserved
Page 82 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
2745
2746
Semantic Rules
2747
2748
2749
1. Let AE denote the set of all persistent AuditableEvent instances in the Registry. The
following steps will eliminate instances in AE that do not satisfy the conditions of the
specified filters.
2750
a) If AE is empty then continue to the next numbered rule.
2751
2752
2753
b) If an AuditableEventFilter is not specified then go to the next step; otherwise, let x be an
auditable event in AE. If x does not satisfy the AuditableEventFilter, then remove x from
AE. If AE is empty then continue to the next numbered rule.
2754
2755
2756
2757
2758
c) If a RegistryObjectQuery element is not specified then go to the next step; otherwise, let
x be a remaining auditable event in AE. Treat RegistryObjectQuery element as follows:
Let RO be the result set of the RegistryObjectQuery as defined in Section 8.2.2. If x is
not an auditable event for some registry object in RO, then remove x from AE. If AE is
empty then continue to the next numbered rule.
2759
2760
2761
2762
2763
d) If a RegistryEntryQuery element is not specified then go to the next step; otherwise, let x
be a remaining auditable event in AE. Treat RegistryEntryQuery element as follows: Let
RE be the result set of the RegistryEntryQuery as defined in Section 8.2.3. If x is not an
auditable event for some registry entry in RE, then remove x from AE. If AE is empty
then continue to the next numbered rule.
2764
2765
2766
e) If a UserQuery is not specified then go to the next step; otherwise, let x be a remaining
auditable event in AE. If the defining user of x does not satisfy the UserQuery, then
remove x from AE. If AE is empty then continue to the next numbered rule.
2767
2768
f) Let AE be the set of remaining AuditableEvent instances. Evaluate inherited
RegistryObjectQuery over AE as explained in Section 8.2.2.
2769
2770
2. If AE is empty, then raise the warning: auditable event query result is empty; otherwise set
AE to be the result of the AuditableEventQuery.
2771
2772
3. Return the result and any accumulated warnings or exceptions (in the RegistryErrorList)
within the RegistryResponse.
2773
Examples
2774
2775
2776
2777
2778
2779
2780
2781
2782
2783
2784
2785
2786
2787
2788
A Registry client has registered an item and it has been assigned a name "urn:path:myitem". The
client is now interested in all events since the beginning of the year that have impacted that item.
The following query will return a set of AuditableEvent instances for all such events.
<AdhocQueryRequest>
<ResponseOption returnType = "LeafClass"/>
<FilterQuery>
<AuditableEventQuery>
<AuditableEventFilter>
<Clause>
<SimpleClause leftArgument = "timestamp">
<RationalClause logicalPredicate = "GE">
DateTimeClause>2000-01-01T00:00:00-05:00</DateTimeClause>
</RationalClause>
</SimpleClause>
Copyright © OASIS, 2002. All Rights Reserved
Page 83 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
2789
2790
2791
2792
2793
2794
2795
2796
2797
2798
2799
2800
2801
2802
2803
2804
2805
</Clause>
</AuditableEventFilter>
<RegistryEntryQuery>
<NameBranch>
<LocalizedStringFilter>
<Clause>
<SimpleClause leftArgument = "value">
<StringClause stringPredicate = "Equal">urn:path:myitem</StringClause>
</SimpleClause>
</Clause>
</LocalizedStringFilter>
</NameBranch>
</RegistryEntryQuery>
</AuditableEventQuery>
</FilterQuery>
</AdhocQueryRequest
2806
2807
2808
2809
2810
2811
2812
2813
2814
2815
2816
2817
2818
2819
2820
2821
2822
2823
2824
2825
2826
2827
2828
2829
2830
2831
2832
2833
2834
2835
2836
2837
2838
2839
2840
2841
2842
2843
2844
A client company has many registered objects in the Registry. The Registry allows events
submitted by other organizations to have an impact on your registered items, e.g. new
classifications and new associations. The following query will return a set of identifiers for all
auditable events, invoked by some other party, that had an impact on an item submitted by
“myorg”.
<AdhocQueryRequest>
<ResponseOption returnType = "LeafClass"/>
<FilterQuery>
<AuditableEventQuery>
<RegistryEntryQuery>
<TargetAssociationBranch>
<AssociationFilter>
<Clause>
<SimpleClause leftArgument = "associationType">
<StringClause stringPredicate = "Equal">SubmitterOf</StringClause>
</SimpleClause>
</Clause>
</AssociationFilter>
<OrganizationQuery>
<NameBranch>
<LocalizedStringFilter>
<Clause>
<SimpleClause leftArgument = "value">
<StringClause stringPredicate = "Equal">myorg</StringClause>
</SimpleClause>
</Clause>
</LocalizedStringFilter>
</NameBranch>
</OrganizationQuery>
</TargetAssociationBranch>
</RegistryEntryQuery>
<UserBranch>
<OrganizationQuery>
<NameBranch>
<LocalizedStringFilter>
<Clause>
<SimpleClause leftArgument = "value">
<StringClause stringPredicate = "NotEqual">myorg</StringClause>
Copyright © OASIS, 2002. All Rights Reserved
Page 84 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
2845
2846
2847
2848
2849
2850
2851
2852
2853
2854
</SimpleClause>
</Clause>
</LocalizedStringFilter>
</NameBranch>
</OrganizationQuery>
</UserBranch>
</AuditableEventQuery>
</FilterQuery>
</AdhocQueryRequest>
2855
8.2.6 ClassificationQuery
2856
Purpose
2857
2858
To identify a set of classification instances as the result of a query over selected registry
metadata.
2859
ebRIM Binding
Classification
Registry
Object
Registry Object
Registry
Entry
Classification
Scheme
Figure 36: ebRIM Binding for ClassificationQuery
2860
2861
2862
2863
2864
2865
2866
2867
2868
2869
2870
2871
2872
2873
2874
2875
2876
2877
2878
2879
2880
2881
2882
2883
2884
Classification
Node
Definition
<complexType name = "ClassificationQueryType">
<complexContent>
<extension base = "tns:RegistryObjectQueryType">
<sequence>
<element ref = "tns:ClassificationFilter" minOccurs = "0" maxOccurs="1"/>
<element ref = "tns:ClassificationSchemeQuery" minOccurs = "0" maxOccurs="1"/>
<element ref = "tns:ClassificationNodeQuery" minOccurs = "0" maxOccurs="1"/>
<element ref = "tns:RegistryObjectQuery" minOccurs = "0" maxOccurs="1"/>
<element ref = "tns:RegistryEntryQuery" minOccurs = "0" maxOccurs="1"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name = "ClassificationQuery" type = "tns:ClassificationQueryType"/>
<element name="ClassificationQueryResult">
<complexType>
<choice minOccurs="0" maxOccurs="unbounded">
<element ref="rim:ObjectRef" />
<element ref="rim:RegistryObject" />
<element ref="rim:Classification" />
</choice>
Copyright © OASIS, 2002. All Rights Reserved
Page 85 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
2885
2886
2887
</complexType>
</element>
2888
Semantic Rules
2889
2890
1. Let C denote the set of all persistent Classification instances in the Registry. The following
steps will eliminate instances in C that do not satisfy the conditions of the specified filters.
2891
a) If C is empty then continue to the next numbered rule.
2892
2893
2894
2895
b) If a ClassificationFilter element is not directly contained in the ClassificationQuery
element, then go to the next step; otherwise let x be an classification instance in C. If x
does not satisfy the ClassificationFilter then remove x from C. If C is empty then
continue to the next numbered rule.
2896
2897
2898
2899
c) If a ClassificationSchemeQuery is not specified then go to the next step; otherwise, let x
be a remaining classification in C. If the defining classification scheme of x does not
satisfy the ClassificationSchemeQuery as defined in Section 8.2.8, then remove x from C.
If C is empty then continue to the next numbered rule.
2900
2901
2902
2903
d) If a ClassificationNodeQuery is not specified then go to the next step; otherwise, let x be
a remaining classification in C. If the classification node of x does not satisfy the
ClassificationNodeQuery as defined in Section 8.2.7, then remove x from C. If C is
empty then continue to the next numbered rule.
2904
2905
2906
2907
2908
e) If a RegistryObjectQuery element is not specified then go to the next step; otherwise, let
x be a remaining classification in C. Treat RegistryObjectQuery element as follows: Let
RO be the result set of the RegistryObjectQuery as defined in Section 8.2.2. If x is not a
classification of at least one registry object in RO, then remove x from C. If C is empty
then continue to the next numbered rule.
2909
2910
2911
2912
2913
f) If a RegistryEntryQuery element is not specified then go to the next step; otherwise, let x
be a remaining classification in C. Treat RegistryEntryQuery element as follows: Let RE
be the result set of the RegistryEntryQuery as defined in Section 8.2.3. If x is not a
classification of at least one registry entry in RE, then remove x from C. If C is empty
then continue to the next numbered rule.
2914
2915
2. If C is empty, then raise the warning: classification query result is empty; otherwise
otherwise, set C to be the result of the ClassificationQuery.
2916
2917
3. Return the result and any accumulated warnings or exceptions (in the RegistryErrorList)
within the RegistryResponse.
2918
8.2.7 ClassificationNodeQuery
2919
Purpose
2920
2921
To identify a set of classification node instances as the result of a query over selected registry
metadata.
2922
ebRIM Binding
Copyright © OASIS, 2002. All Rights Reserved
Page 86 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
Classification
Node
Registry
Object
Parent
Children
Classification
Scheme
Classification
Node
Classification
Node
Figure 37: ebRIM Binding for ClassificationNodeQuery
2923
2924
2925
2926
2927
2928
2929
2930
2931
2932
2933
2934
2935
2936
2937
2938
2939
2940
2941
2942
2943
2944
2945
2946
2947
2948
2949
2950
2951
Definition
2952
Semantic Rules
2953
2954
2955
1. Let CN denote the set of all persistent ClassificationNode instances in the Registry. The
following steps will eliminate instances in CN that do not satisfy the conditions of the
specified filters.
<complexType name="ClassificationNodeQueryType">
<complexContent>
<extension base="tns:RegistryObjectQueryType">
<sequence>
<element ref="tns:ClassificationNodeFilter" minOccurs="0" maxOccurs="1" />
<element ref="tns:ClassificationSchemeQuery" minOccurs="0" maxOccurs="1" />
<element name="ClassificationNodeParentBranch" type="ClassificationNodeQueryType" minOccurs="0"
maxOccurs="1" />
<element name="ClassificationNodeChildrenBranch" type="ClassificationNodeQueryType"
minOccurs="0" maxOccurs="unbounded" />
</sequence>
</extension>
</complexContent>
</complexType>
<element name="ClassificationNodeQuery" type="tns:ClassificationNodeQueryType" />
<element name="ClassificationNodeQueryResult">
<complexType>
<choice minOccurs="0" maxOccurs="unbounded">
<element ref="rim:ObjectRef" />
<element ref="rim:RegistryObject" />
<element ref="rim:ClassificationNode" />
</choice>
</complexType>
</element>
2956
a) If CN is empty then continue to the next numbered rule.
2957
2958
2959
b) If a ClassificationNodeFilter is not specified then go to the next step; otherwise, let x be a
classification node in CN. If x does not satisfy the ClassificationNodeFilter then remove
x from CN. If CN is empty then continue to the next numbered rule.
Copyright © OASIS, 2002. All Rights Reserved
Page 87 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
2960
2961
2962
2963
c) If a ClassificationSchemeQuery is not specified then go to the next step; otherwise, let x
be a remaining classification node in CN. If the defining classification scheme of x does
not satisfy the ClassificationSchemeQuery as defined in Section 8.2.8, then remove x
from CN. If CN is empty then continue to the next numbered rule.
2964
2965
2966
2967
2968
2969
2970
2971
2972
2973
2974
2975
2976
2977
d) If a ClassificationNodeParentBranch element is not specified, then go to the next step;
otherwise, let x be a remaining classification node in CN and execute the following
paragraph with n=x.
Let n be a classification node instance. If n does not have a parent node (i.e. if n is a base
level node), then remove x from CN and go to the next step; otherwise, let p be the parent
node of n. If a ClassificationNodeFilter element is directly contained in the
ClassificationNodeParentBranch and if p does not satisfy the ClassificationNodeFilter,
then remove x from CN. If CN is empty then continue to the next numbered rule. If a
ClassificationSchemeQuery element is directly contained in the
ClassificationNodeParentBranch and if defining classification scheme of p does not
satisfy the ClassificationSchemeQuery, then remove x from CN. If CN is empty then
continue to the next numbered rule.
If another ClassificationNodeParentBranch element is directly contained within this
ClassificationNodeParentBranch element, then repeat the previous paragraph with n=p.
2978
2979
2980
2981
2982
2983
2984
2985
2986
2987
2988
2989
2990
2991
2992
2993
2994
2995
2996
2997
2998
e) If a ClassificationNodeChildrenBranch element is not specified, then continue to the next
numbered rule; otherwise, let x be a remaining classification node in CN. If x is not the
parent node of some ClassificationNode instance, then remove x from CN and if CN is
empty continue to the next numbered rule; otherwise, treat each
ClassificationNodeChildrenBranch element separately and execute the following
paragraph with n = x.
Let n be a classification node instance. If a ClassificationNodeFilter element is not
specified within the ClassificationNodeChildrenBranch element then let CNC be the set
of all classification nodes that have n as their parent node; otherwise, let CNC be the set
of all classification nodes that satisfy the ClassificationNodeFilter and have n as their
parent node. If CNC is empty, then remove x from CN and if CN is empty continue to the
next numbered rule; otherwise, let c be any member of CNC. If a
ClassificationSchemeQuery element is directly contained in the
ClassificationNodeChildrenBranch and if the defining classification scheme of c does not
satisfy the ClassificationSchemeQuery then remove c from CNC. If CNC is empty then
remove x from CN. If CN is empty then continue to the next numbered rule; otherwise,
let y be an element of CNC and continue with the next paragraph.
If the ClassificationNodeChildrenBranch element is terminal, i.e. if it does not directly
contain another ClassificationNodeChildrenBranch element, then continue to the next
numbered rule; otherwise, repeat the previous paragraph with the new
ClassificationNodeChildrenBranch element and with n = y.
2999
3000
f) Let CN be the set of remaining ClassificationNode instances. Evaluate inherited
RegistryObjectQuery over CN as explained in Section 8.2.2.
3001
3002
2. If CN is empty, then raise the warning: classification node query result is empty; otherwise
set CN to be the result of the ClassificationNodeQuery.
3003
3004
3. Return the result and any accumulated warnings or exceptions (in the RegistryErrorList)
within the RegistryResponse.
Copyright © OASIS, 2002. All Rights Reserved
Page 88 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
3005
Path Filter Expression usage in ClassificationNodeFilter
3006
3007
3008
The path filter expression is used to match classification nodes in ClassificationNodeFilter
elements involving the path attribute of the ClassificationNode class as defied by the getPath
method in [ebRIM].
3009
3010
The path filter expressions are based on a very small and proper sub-set of location path syntax
of XPath.
3011
3012
3013
3014
3015
The path filter expression syntax includes support for matching multiple nodes by using wild
card syntax as follows:
Use of ‘*’ as a wildcard in place of any path element in the pathFilter.
Use of ‘//’ syntax to denote any descendent of a node in the pathFilter. Support for ‘//’ syntax
is optional.
3016
3017
3018
3019
3020
3021
3022
3023
It is defined by the following BNF grammar:
3024
3025
3026
In the above grammer, schemeId is the id attribute of the ClassificationScheme instance. In the
above grammar nodeCode is defined by NCName production as defined by
http://www.w3.org/TR/REC-xml-names/#NT-NCName.
3027
3028
3029
The semantic rules for the ClassificationNodeFilter element allow the use of path attribute as a
filter that is based on the EQUAL clause. The pattern specified for matching the EQUAL clause
is a PATH Filter expression.
3030
3031
3032
3033
3034
3035
3036
3037
3038
3039
3040
3041
3042
This is illustrated in the following example that matches all second level nodes in
ClassificationScheme with id ‘Geography-id’ and with code ‘Japan’:
3043
Use Cases and Examples of Path Filter Expressions
3044
3045
3046
3047
3048
3049
3050
3051
3052
3053
3054
3055
The following table lists various use cases and examples using the sample Geography scheme
below:
pathFilter ::= '/' schemeId nodePath
nodePath ::= slashes nodeCode
| slashes ‘*’
| slashes nodeCode ( nodePath )?
Slashes ::= ‘/’ | ‘//’
<ClassificationNodeQuery>
<ClassificationNodeFilter>
<Clause>
<SimpleClause leftArgument = "path">
<StringClause stringPredicate = "Equal">//Geography-id/*/Japan</StringClause>
</SimpleClause>
</Clause>
</ClassificationNodeFilter>
</ClassificationNodeQuery>
<ClassificationScheme id='Geography-id' name="Geography”/>
<ClassificationNode id="NorthAmerica-id" parent="Geography-id" code=NorthAmerica" />
<ClassificationNode id="UnitedStates-id" parent="NorthAmerica-id" code="UnitedStates" />
<ClassificationNode id="Asia-id" parent="Geography-id" code="Asia" />
<ClassificationNode id="Japan-id" parent="Asia-id" code="Japan" />
<ClassificationNode id="Tokyo-id" parent="Japan-id" code="Tokyo" />
Copyright © OASIS, 2002. All Rights Reserved
Page 89 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
Table 8: Path Filter Expressions for Use Cases
3056
Use Case
PATH Expression
Description
Match all nodes in first
level that have a specified
value
/Geography-id/NorthAmerica
Find all children of first
level node whose code is
“NorthAmerica”
Match all nodes whose first level
/Geography-id/NorthAmerica/* path element has code
"NorthAmerica"
Match all nodes that have
a specified value
regardless of level
/ Geography-id//Japan
Find all nodes with code ''Japan”
Match all nodes in the
second level that have a
specified value
/Geography-id/*/Japan
Find all second level nodes with
code 'Japan'
Match all nodes in the
3rd level that have a
specified value
/ Geography-id/*/*/Tokyo
Find all third level nodes with
code 'Tokyo'
Find all first level nodes whose
code is 'NorthAmerica'
3057
Examples
3058
3059
3060
3061
3062
3063
3064
3065
3066
3067
3068
3069
3070
3071
3072
3073
3074
3075
3076
3077
3078
3079
3080
3081
3082
3083
A client application wishes to identify all of the classification nodes in the first three levels of a
classification scheme hierarchy. The client knows that the name of the underlying classification
scheme is “urn:ebxml:cs:myscheme”. The following query identifies all nodes at the first three
levels.
<AdhocQueryRequest>
<ResponseOption returnType = "LeafClass"/>
<FilterQuery>
<ClassificationNodeQuery>
<ClassificationNodeFilter>
<Clause>
<SimpleClause leftArgument = "levelNumber">
<RationalClause logicalPredicate = "LE">
<IntClause>3</IntClause>
</RationalClause>
</SimpleClause>
</Clause>
</ClassificationNodeFilter>
<ClassificationSchemeQuery>
<NameBranch>
<LocalizedStringFilter>
<Clause>
<SimpleClause leftArgument = "value">
<StringClause stringPredicate = "Equal">urn:ebxml:cs:myscheme</StringClause>
</SimpleClause>
</Clause>
Copyright © OASIS, 2002. All Rights Reserved
Page 90 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
3084
3085
3086
3087
3088
3089
3090
</LocalizedStringFilter>
</NameBranch>
</ClassificationSchemeQuery>
</ClassificationNodeQuery>
</FilterQuery>
</AdhocQueryRequest>
3091
3092
If, instead, the client wishes all levels returned, they could simply delete the
ClassificationNodeFilter element from the query.
3093
3094
3095
3096
3097
3098
3099
3100
3101
3102
3103
3104
3105
3106
3107
3108
3109
The following query finds all children nodes of a first level node whose code is NorthAmerica.
3110
3111
3112
3113
3114
3115
3116
3117
3118
3119
3120
3121
3122
3123
3124
3125
3126
The following query finds all third level nodes with code of Tokyo.
3127
8.2.8 ClassificationSchemeQuery
3128
Purpose
3129
3130
To identify a set of classification scheme instances as the result of a query over selected registry
metadata.
3131
ebRIM Binding
<AdhocQueryRequest>
<ResponseOption returnType = "LeafClass"/>
<FilterQuery>
<ClassificationNodeQuery>
<ClassificationNodeFilter>
<Clause>
<SimpleClause leftArgument = "path">
<StringClause stringPredicate = "Equal">/Geography-id/NorthAmerica/*</StringClause>
</SimpleClause>
</Clause>
</ClassificationNodeFilter>
</ClassificationNodeQuery>
</FilterQuery>
</AdhocQueryRequest>
<AdhocQueryRequest>
<ResponseOption returnType = "LeafClass" returnComposedObjects = "True"/>
<FilterQuery>
<ClassificationNodeQuery>
<ClassificationNodeFilter>
<Clause>
<SimpleClause leftArgument = "path">
<StringClause stringPredicate = "Equal">/Geography-id/*/*/Tokyo</StringClause>
</SimpleClause>
</Clause>
</ClassificationNodeFilter>
</ClassificationNodeQuery>
</FilterQuery>
</AdhocQueryRequest>
Copyright © OASIS, 2002. All Rights Reserved
Page 91 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
Classification Scheme
Registry
Entry
Figure 38: ebRIM Binding for ClassificationSchemeQuery
3132
3133
3134
3135
3136
3137
3138
3139
3140
3141
3142
3143
3144
3145
3146
3147
3148
3149
3150
3151
3152
3153
3154
3155
3156
Definition
3157
Semantic Rules
3158
3159
3160
1. Let CS denote the set of all persistent ClassificationScheme instances in the Registry. The
following steps will eliminate instances in CS that do not satisfy the conditions of the
specified filters.
<complexType name="ClassificationSchemeQueryType">
<complexContent>
<extension base="tns:RegistryEntryQueryType">
<sequence>
<element ref="tns:ClassificationSchemeFilter" minOccurs="0" maxOccurs="1" />
</sequence>
</extension>
</complexContent>
</complexType>
<element name="ClassificationSchemeQuery" type="tns:ClassificationSchemeQueryType" />
<element name = "ClassificationSchemeQueryResult">
<complexType>
<choice minOccurs = "0" maxOccurs = "unbounded">
<element ref = "rim:ObjectRef"/>
<element ref = "rim:RegistryObject"/>
<element ref = "rim:RegistryEntry"/>
<element ref = "rim:ClassificationScheme"/>
</choice>
</complexType>
</element>
3161
a) If CS is empty then continue to the next numbered rule.
3162
3163
3164
b) If a ClassificationSchemeFilter is not specified then go to the next step; otherwise, let x
be a classification scheme in CS. If x does not satisfy the ClassificationSchemeFilter,
then remove x from CS. If CS is empty then continue to the next numbered rule.
3165
3166
c) Let CS be the set of remaining ClassificationScheme instances. Evaluate inherited
RegistryEntryQuery over CS as explained in Section 8.2.3.
3167
3168
2. If CS is empty, then raise the warning: classification scheme query result is empty; otherwise,
set CS to be the result of the ClassificationSchemeQuery.
3169
3170
3. Return the result and any accumulated warnings or exceptions (in the RegistryErrorList)
within the RegistryResponse.
3171
Examples
3172
A client application wishes to identify all classification scheme instances in the Registry.
Copyright © OASIS, 2002. All Rights Reserved
Page 92 of 188
OASIS/ebXML Registry Services Specification v3.0
3173
3174
3175
3176
3177
3178
July 2017
<AdhocQueryRequest>
<ResponseOption returnType = "LeafClass"/>
<FilterQuery>
<ClassificationSchemeQuery/>
</FilterQuery>
</AdhocQueryRequest>
3179
3180
8.2.9 RegistryPackageQuery
3181
Purpose
3182
3183
To identify a set of registry package instances as the result of a query over selected registry
metadata.
3184
ebRIM Binding
Registry
Package
Registry
Entry
Registry
Object
Figure 39: ebRIM Binding for RegistryPackageQuery
3185
3186
3187
3188
3189
3190
3191
3192
3193
3194
3195
3196
3197
3198
3199
3200
3201
3202
3203
3204
3205
3206
3207
3208
3209
3210
3211
Registry
Entry
Definition
<complexType name="RegistryPackageQueryType">
<complexContent>
<extension base="tns:RegistryEntryQueryType">
<sequence>
<element ref="tns:RegistryPackageFilter" minOccurs="0" maxOccurs="1" />
<element ref="tns:RegistryObjectQuery" minOccurs="0" maxOccurs="unbounded" />
<element ref="tns:RegistryEntryQuery" minOccurs="0" maxOccurs="unbounded" />
</sequence>
</extension>
</complexContent>
</complexType>
<element name="RegistryPackageQuery" type="tns:RegistryPackageQueryType" />
<element name="RegistryPackageQueryResult">
<complexType>
<choice minOccurs="0" maxOccurs="unbounded">
<element ref="rim:ObjectRef" />
<element ref="rim:RegistryEntry" />
<element ref="rim:RegistryObject" />
<element ref="rim:RegistryPackage" />
</choice>
</complexType>
</element>
Copyright © OASIS, 2002. All Rights Reserved
Page 93 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
3212
Semantic Rules
3213
3214
3215
1. Let RP denote the set of all persistent RegistryPackage instances in the Registry. The
following steps will eliminate instances in RP that do not satisfy the conditions of the
specified filters.
3216
a)
If RP is empty then continue to the next numbered rule.
3217
3218
3219
3220
b)
If a RegistryPackageFilter is not specified, then continue to the next numbered rule;
otherwise, let x be a registry package instance in RP. If x does not satisfy the
RegistryPackageFilter then remove x from RP. If RP is empty then continue to the next
numbered rule.
3221
3222
3223
3224
3225
3226
3227
3228
3229
3230
c)
If a RegistryObjectQuery element is directly contained in the RegistryPackageQuery
element then treat each RegistryObjectQuery as follows: let RO be the set of
RegistryObject instances returned by the RegistryObjectQuery as defined in Section 8.2.2
and let PO be the subset of RO that are members of the package x. If PO is empty, then
remove x from RP. If RP is empty then continue to the next numbered rule. If a
RegistryEntryQuery element is directly contained in the RegistryPackageQuery element
then treat each RegistryEntryQuery as follows: let RE be the set of RegistryEntry
instances returned by the RegistryEntryQuery as defined in Section 8.2.3 and let PE be
the subset of RE that are members of the package x. If PE is empty, then remove x from
RP. If RP is empty then continue to the next numbered rule.
3231
3232
d)
Let RP be the set of remaining RegistryPackage instances. Evaluate inherited
RegistryEntryQuery over RP as explained in Section 8.2.3.
3233
3234
2.
If RP is empty, then raise the warning: registry package query result is empty; otherwise set
RP to be the result of the RegistryPackageQuery.
3235
3236
3.
Return the result and any accumulated warnings or exceptions (in the RegistryErrorList)
within the RegistryResponse.
3237
Examples
3238
3239
3240
3241
3242
3243
3244
3245
3246
3247
3248
3249
3250
3251
3252
3253
3254
3255
3256
3257
A client application wishes to identify all package instances in the Registry that contain an
Invoice extrinsic object as a member of the package.
<AdhocQueryRequest>
<ResponseOption returnType = "LeafClass"/>
<FilterQuery>
<RegistryPackageQuery>
<RegistryEntryQuery>
<RegistryEntryFilter>
<Clause>
<SimpleClause leftArgument = "objectType">
<StringClause stringPredicate = "Equal">Invoice</StringClause>
</SimpleClause>
</Clause>
</RegistryEntryFilter>
</RegistryEntryQuery>
</RegistryPackageQuery>
</FilterQuery>
</AdhocQueryRequest>
Copyright © OASIS, 2002. All Rights Reserved
Page 94 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
3258
3259
3260
3261
3262
3263
3264
3265
3266
3267
3268
A client application wishes to identify all package instances in the Registry that are not empty.
3269
3270
3271
3272
3273
3274
A client application wishes to identify all package instances in the Registry that are empty. Since
the RegistryPackageQuery is not set up to do negations, clients will have to do two separate
RegistryPackageQuery requests, one to find all packages and another to find all non-empty
packages, and then do the set difference themselves. Alternatively, they could do a more
complex RegistryEntryQuery and check that the packaging association between the package and
its members is non-existent.
3275
3276
3277
3278
Note: A registry package is an intrinsic RegistryEntry instance that is completely determined by
its associations with its members. Thus a RegistryPackageQuery can always be re-specified as an
equivalent RegistryEntryQuery using appropriate “Source” and “Target” associations. However,
the equivalent RegistryEntryQuery is often more complicated to write.
3279
8.2.10 ExtrinsicObjectQuery
3280
Purpose
3281
3282
To identify a set of extrinsic object instances as the result of a query over selected registry
metadata.
<AdhocQueryRequest>
<ResponseOption returnType = "LeafClass"/>
<FilterQuery>
<RegistryPackageQuery>
<RegistryObjectQuery/>
</RegistryPackageQuery>
</FilterQuery>
</AdhocQueryRequest>
Extrinsic Object
Registry
Entry
3283
3284
ebRIM Binding
3285
3286
3287
3288
3289
3290
3291
3292
3293
3294
3295
3296
3297
Definition
Figure 40: ebRIM Binding for ExtrinsicObjectQuery
<complexType name="ExtrinsicObjectQueryType">
<complexContent>
<extension base="tns:RegistryEntryQueryType">
<sequence>
<element ref="tns:ExtrinsicObjectFilter" minOccurs="0" maxOccurs="1" />
</sequence>
</extension>
</complexContent>
</complexType>
<element name="ExtrinsicObjectQuery" type="tns:ExtrinsicObjectQueryType" />
Copyright © OASIS, 2002. All Rights Reserved
Page 95 of 188
OASIS/ebXML Registry Services Specification v3.0
3298
3299
3300
3301
3302
3303
3304
3305
3306
3307
3308
<element name="ExtrinsicObjectQueryResult">
<complexType>
<choice minOccurs="0" maxOccurs="unbounded">
<element ref="rim:ObjectRef" />
<element ref="rim:RegistryEntry" />
<element ref="rim:RegistryObject" />
<element ref="rim:ExtrinsicObject" />
</choice>
</complexType>
</element>
3309
Semantic Rules
3310
3311
3312
1.
July 2017
Let EO denote the set of all persistent ExtrinsicObject instances in the Registry. The
following steps will eliminate instances in EO that do not satisfy the conditions of the
specified filters.
3313
a) If EO is empty then continue to the next numbered rule.
3314
3315
3316
b) If a ExtrinsicObjectFilter is not specified then go to the next step; otherwise, let x be an
extrinsic object in EO. If x does not satisfy the ExtrinsicObjectFilter then remove x from
EO. If EO is empty then continue to the next numbered rule.
3317
3318
c) Let EO be the set of remaining ExtrinsicObject instances. Evaluate inherited
RegistryEntryQuery over EO as explained in Section 8.2.3.
3319
3320
2.
If EO is empty, then raise the warning: extrinsic object query result is empty; otherwise, set
EO to be the result of the ExtrinsicObjectQuery.
3321
3322
3323
3.
Return the result and any accumulated warnings or exceptions (in the RegistryErrorList)
within the RegistryResponse.
Copyright © OASIS, 2002. All Rights Reserved
Page 96 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
3324
3325
8.2.11 OrganizationQuery
3326
Purpose
3327
3328
To identify a set of organization instances as the result of a query over selected registry
metadata.
3329
3330
ebRIM Binding
3331
Organization
3332
Registry
Object
3333
3334
Parent
Organization
3335
3338
Person
Name
3340
Postal
Address
Email
Address
Telephone
Number
Figure 41: ebRIM Binding for OrganizationQuery
3341
3342
3343
3344
3345
3346
3347
3348
3349
3350
3351
3352
3353
3354
3355
3356
3357
3358
3359
3360
3361
3362
3363
3364
3365
Telephone
Number
User
3337
3339
Organization
Postal
Address
3336
Children
Definition
<complexType name="OrganizationQueryType">
<complexContent>
<extension base="tns:RegistryObjectQueryType">
<sequence>
<element ref="tns:OrganizationFilter" minOccurs="0" maxOccurs="1" />
<element ref="tns:PostalAddressFilter" minOccurs="0" maxOccurs="1" />
<element ref="tns:TelephoneNumberFilter" minOccurs="0" maxOccurs="unbounded" />
<element ref="tns:UserQuery" minOccurs="0" maxOccurs="1" />
<element name="OrganizationParentBranch" type="tns:OrganizationQueryType" minOccurs="0
" maxOccurs="1" />
<element name="OrganizationChildrenBranch" type="tns:OrganizationQueryType" minOccurs="0"
maxOccurs="unbounded" />
</sequence>
</extension>
</complexContent>
</complexType>
<element name="OrganizationQuery" type="tns:OrganizationQueryType" />
<element name="OrganizationQueryResult">
<complexType>
<choice minOccurs="0" maxOccurs="unbounded">
<element ref="rim:ObjectRef" />
Copyright © OASIS, 2002. All Rights Reserved
Page 97 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
3366
3367
3368
3369
3370
3371
<element ref="rim:RegistryObject" />
<element ref="rim:Organization" />
</choice>
</complexType>
</element>
3372
Semantic Rules
3373
3374
3375
1. Let ORG denote the set of all persistent Organization instances in the Registry. The
following steps will eliminate instances in ORG that do not satisfy the conditions of the
specified filters.
3376
a)
If ORG is empty then continue to the next numbered rule.
3377
3378
3379
3380
b)
If an OrganizationFilter element is not directly contained in the OrganizationQuery
element, then go to the next step; otherwise let x be an organization instance in ORG. If x
does not satisfy the OrganizationFilter then remove x from ORG. If ORG is empty then
continue to the next numbered rule.
3381
3382
3383
3384
c)
If a PostalAddressFilter element is not directly contained in the OrganizationQuery
element then go to the next step; otherwise, let x be an organization in ORG. If postal
address of x does not satisfy the PostalAddressFilter then remove x from ORG. If ORG is
empty then continue to the next numbered rule.
3385
3386
3387
3388
d)
If no TelephoneNumberFilter element is directly contained in the OrganizationQuery
element then go to the next step; otherwise, let x be an organization in ORG. If any of the
TelephoneNumberFilters isn’t satisfied by all of the telephone numbers of x then remove
x from ORG. If ORG is empty then continue to the next numbered rule.
3389
3390
3391
e)
If a UserQuery is not specified then go to the next step; otherwise, let x be a remaining
organization in ORG. If the defining primary contact of x does not satisfy the UserQuery,
then remove x from ORG. If ORG is empty then continue to the next numbered rule.
3392
3393
3394
3395
3396
3397
3398
3399
3400
3401
f)
If a OrganizationParentBranch element is not specified within the OrganizationQuery,
then go to the next step; otherwise, let x be an extrinsic object in ORG. Execute the
following paragraph with o = x:
Let o be an organization instance. If an OrganizationFilter is not specified within the
OrganizationParentBranch and if o has no parent (i.e. if o is a root organization in the
Organization hierarchy), then remove x from ORG; otherwise, let p be the parent
organization of o. If p does not satisfy the OrganizationFilter, then remove x from ORG.
If ORG is empty then continue to the next numbered rule.
If another OrganizationParentBranch element is directly contained within this
OrganizationParentBranch element, then repeat the previous paragraph with o = p.
3402
3403
3404
3405
3406
g)
If a OrganizationChildrenBranch element is not specified, then continue to the next
numbered rule; otherwise, let x be a remaining organization in ORG. If x is not the parent
node of some organization instance, then remove x from ORG and if ORG is empty
continue to the next numbered rule; otherwise, treat each OrganizationChildrenBranch
element separately and execute the following paragraph with n = x.
Copyright © OASIS, 2002. All Rights Reserved
Page 98 of 188
OASIS/ebXML Registry Services Specification v3.0
3407
3408
3409
3410
3411
3412
3413
3414
3415
3416
3417
3418
3419
3420
3421
3422
3423
3424
July 2017
Let n be an organization instance. If an OrganizationFilter element is not specified within
the OrganizationChildrenBranch element then let ORGC be the set of all organizations
that have n as their parent node; otherwise, let ORGC be the set of all organizations that
satisfy the OrganizationFilter and have n as their parent node. If ORGC is empty, then
remove x from ORG and if ORG is empty continue to the next numbered rule; otherwise,
let c be any member of ORGC. If a PostalAddressFilter element is directly contained in
the OrganizationChildrenBranch and if the postal address of c does not satisfy the
PostalAddressFilter then remove c from ORGC. If ORGC is empty then remove x from
ORG. If ORG is empty then continue to the next numbered rule. If no
TelephoneNumberFilter element is directly contained in the OrganizationChildrenBranch
and if any of the TelephoneNumberFilters isn’t satisfied by all of the telephone numbers
of c then remove c from ORGC. If ORGC is empty then remove x from ORG. If ORG is
empty then continue to the next numbered rule; otherwise, let y be an element of ORGC
and continue with the next paragraph.
If the OrganizationChildrenBranch element is terminal, i.e. if it does not directly contain
another OrganizationChildrenBranch element, then continue to the next numbered rule;
otherwise, repeat the previous paragraph with the new OrganizationChildrenBranch
element and with n = y.
3425
3426
h)
Let ORG be the set of remaining Organization instances. Evaluate inherited
RegistryObjectQuery over ORG as explained in Section 8.2.2.
3427
3428
2.
If ORG is empty, then raise the warning: organization query result is empty; otherwise set
ORG to be the result of the OrganizationQuery.
3429
3430
3.
Return the result and any accumulated warnings or exceptions (in the RegistryErrorList)
within the RegistryResponse.
3431
Examples
3432
3433
3434
3435
3436
3437
3438
3439
3440
3441
3442
3443
3444
3445
3446
3447
3448
3449
3450
3451
3452
3453
3454
3455
A client application wishes to identify a set of organizations, based in France, that have
submitted a PartyProfile extrinsic object this year.
<AdhocQueryRequest>
<ResponseOption returnType = "LeafClass" returnComposedObjects = "True”/>
<FilterQuery>
<OrganizationQuery>
<SourceAssociationBranch>
<AssociationFilter>
<Clause>
<SimpleClause leftArgument = "associationType">
<StringClause stringPredicate = "Equal">SubmitterOf</StringClause>
</SimpleClause>
</Clause>
</AssociationFilter>
<RegistryObjectQuery>
<RegistryObjectFilter>
<Clause>
<SimpleClause leftArgument = "objectType">
<StringClause stringPredicate = "Equal">CPP</StringClause>
</SimpleClause>
</Clause>
</RegistryObjectFilter>
<AuditableEventQuery>
Copyright © OASIS, 2002. All Rights Reserved
Page 99 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
3456
3457
3458
3459
3460
3461
3462
3463
3464
3465
3466
3467
3468
3469
3470
3471
3472
3473
3474
3475
3476
3477
3478
<AuditableEventFilter>
<Clause>
<SimpleClause leftArgument = "timestamp">
<RationalClause logicalPredicate = "GE">
<DateTimeClause>2000-01-01T00:00:00-05:00</DateTimeClause>
</RationalClause>
</SimpleClause>
</Clause>
</AuditableEventFilter>
</AuditableEventQuery>
</RegistryObjectQuery>
</SourceAssociationBranch>
<PostalAddressFilter>
<Clause>
<SimpleClause leftArgument = "country">
<StringClause stringPredicate = "Equal">France</StringClause>
</SimpleClause>
</Clause>
</PostalAddressFilter>
</OrganizationQuery>
</FilterQuery>
</AdhocQueryRequest>
3479
3480
3481
3482
3483
3484
3485
3486
3487
3488
3489
3490
3491
3492
3493
3494
3495
3496
3497
3498
3499
3500
A client application wishes to identify all organizations that have Corporation named XYZ as a
parent.
3501
8.2.12 ServiceQuery
3502
3503
3504
Purpose
3505
ebRIM Binding
<AdhocQueryRequest>
<ResponseOption returnType = "LeafClass"/>
<FilterQuery>
<OrganizationQuery>
<OrganizationParentBranch>
<NameBranch>
<LocalizedStringFilter>
<Clause>
<SimpleClause leftArgument = "value">
<StringClause stringPredicate = "Equal">XYZ</StringClause>
</SimpleClause>
</Clause>
</LocalizedStringFilter>
</NameBranch>
</OrganizationParentBranch>
</OrganizationQuery>
</FilterQuery>
</AdhocQueryRequest>
To identify a set of service instances as the result of a query over selected registry metadata.
Copyright © OASIS, 2002. All Rights Reserved
Page 100 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
Service
Registry Entry
Service Binding
Registry
Object
Registry
Entry
Figure 42: ebRIM Binding for ServiceQuery
3506
3507
3508
3509
3510
3511
3512
3513
3514
3515
3516
3517
3518
3519
3520
3521
3522
3523
3524
3525
3526
3527
3528
3529
3530
3531
3532
3533
Definition
3534
Semantic Rules
3535
3536
1.
3537
Specification Link
<complexType name="ServiceQueryType">
<complexContent>
<extension base="tns:RegistryEntryQueryType">
<sequence>
<element ref="tns:ServiceFilter" minOccurs="0"
maxOccurs="1" />
<element ref="tns:ServiceBindingBranch" minOccurs="0"
maxOccurs="unbounded" />
</sequence>
</extension>
</complexContent>
</complexType>
<element name="ServiceQuery" type="tns:ServiceQueryType" />
<element name="ServiceQueryResult">
<complexType>
<choice minOccurs="0" maxOccurs="unbounded">
<element ref="rim:ObjectRef" />
<element ref="rim:RegistryObject" />
<element ref="rim:RegistryEntry" />
<element ref="rim:Service" />
</choice>
</complexType>
</element>
Let S denote the set of all persistent Service instances in the Registry. The following steps
will eliminate instances in S that do not satisfy the conditions of the specified filters.
a) If S is empty then continue to the next numbered rule.
Copyright © OASIS, 2002. All Rights Reserved
Page 101 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
3538
3539
3540
b) If a ServicetFilter is not specified then go to the next step; otherwise, let x be a service in
S. If x does not satisfy the ServiceFilter, then remove x from S. If S is empty then
continue to the next numbered rule.
3541
3542
3543
3544
3545
3546
3547
3548
3549
3550
3551
3552
3553
3554
3555
3556
3557
3558
3559
3560
3561
3562
3563
3564
3565
c) If a ServiceBindingBranch is not specified then continue to the next numbered rule;
otherwise, consider each ServiceBindingBranch element separately as follows:
Let SB be the set of all ServiceBinding instances that describe binding of x. Let sb be the
member of SB. If a ServiceBindingFilter element is specified within the
ServiceBindingBranch, and if sb does not satisfy that filter, then remove sb from SB. If
SB is empty then remove x from S. If S is empty then continue to the next numbered rule.
If a SpecificationLinkBranch is not specified within the ServiceBindingBranch then
continue to the next numbered rule; otherwise, consider each SpecificationLinkBranch
element separately as follows:
Let sb be a remaining service binding in SB. Let SL be the set of all specification link
instances sl that describe specification links of sb. If a SpecificationLinkFilter element is
specified within the SpecificationLinkBranch, and if sl does not satisfy that filter, then
remove sl from SL. If SL is empty then remove sb from SB. If SB is empty then remove
x from S. If S is empty then continue to the next numbered rule. If a RegistryObjectQuery
element is specified within the SpecificationLinkBranch then let sl be a remaining
specification link in SL. Treat RegistryObjectQuery element as follows: Let RO be the
result set of the RegistryObjectQuery as defined in Section 8.2.2. If sl is not a
specification link for some registry object in RO, then remove sl from SL. If SL is empty
then remove sb from SB. If SB is empty then remove x from S. If S is empty then
continue to the next numbered rule. If a RegistryEntryQuery element is specified within
the SpecificationLinkBranch then let sl be a remaining specification link in SL. Treat
RegistryEntryQuery element as follows: Let RE be the result set of the
RegistryEntryQuery as defined in Section 8.2.3. If sl is not a specification link for some
registry entry in RE, then remove sl from SL. If SL is empty then remove sb from SB. If
SB is empty then remove x from S. If S is empty then continue to the next numbered rule.
3566
3567
d) Let S be the set of remaining Service instances. Evaluate inherited RegistryEntryQuery
over AE as explained in Section 8.2.3.
3568
3569
2.
If S is empty, then raise the warning: service query result is empty; otherwise set S to be the
result of the ServiceQuery.
3570
3571
3572
3.
Return the result and any accumulated warnings or exceptions (in the RegistryErrorList)
within the RegistryResponse.
Copyright © OASIS, 2002. All Rights Reserved
Page 102 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
3573
3574
8.2.13 FederationQuery
3575
Purpose
3576
To identify a set of federation instances as the result of a query over selected registry metadata.
3577
3578
3579
3580
3581
3582
3583
3584
3585
3586
3587
ebRIM Binding
3588
3589
3590
3591
3592
3593
3594
3595
3596
3597
3598
3599
3600
3601
3602
3603
3604
3605
3606
3607
3608
3609
3610
3611
3612
Definition
3613
Semantic Rules
3614
3615
1. Let F denote the set of all persistent Federation instances in the Registry. The following steps
will eliminate instances in F that do not satisfy the conditions of the specified filters.
3616
Federation
RegistryObject
Registry
Figure 43: ebRIM Binding for FederationQuery
<complexType name = "FederationQueryType">
<complexContent>
<extension base = "tns:RegistryEntryQueryType">
<sequence>
<element ref = "tns:FederationFilter" minOccurs = "0" maxOccurs="1"/>
<element ref = "tns:RegistryQuery" minOccurs = "0" maxOccurs = "unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name = "FederationQuery" type = "tns:FederationQueryType"/>
<element name = "FederationQueryResult">
<complexType>
<choice minOccurs = "0" maxOccurs = "unbounded">
<element ref = "rim:ObjectRef"/>
<element ref = "rim:RegistryObject"/>
<element ref = "rim:RegistryEntry"/>
<element ref = "rim:Federation"/>
</choice>
</complexType>
</element>
a)
If F is empty then continue to the next numbered rule.
Copyright © OASIS, 2002. All Rights Reserved
Page 103 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
3617
3618
3619
b)
If a FederationFilter is not specified, then continue to the next numbered rule; otherwise,
let x be a federation instance in F. If x does not satisfy the FederationFilter then remove x
from F. If F is empty then continue to the next numbered rule.
3620
3621
3622
3623
3624
c)
If a RegistryQuery element is directly contained in the FederationQuery element then
treat each RegistryQuery as follows: let R be the set of Registry instances returned by the
RegistryQuery as defined in Section and let FR be the subset of R that are members of
the federation x. If FR is empty, then remove x from F. If F is empty then continue to the
next numbered rule.
3625
3626
d)
Let F be the set of remaining Federation instances. Evaluate inherited
RegistryEntryQuery over F as explained in Section.
3627
3628
2.
If F is empty, then raise the warning: federation query result is empty; otherwise set F to be
the result of the FederationQuery.
3629
3630
3.
Return the result and any accumulated warnings or exceptions (in the RegistryErrorList)
within the RegistryResponse.
3631
8.2.14 RegistryQuery
3632
Purpose
3633
To identify a set of registry instances as the result of a query over selected registry metadata.
3634
3635
ebRIM Binding
3636
Registry
3637
Registry
Entry
3638
Figure 44: ebRIM Binding for RegistryQuery
3639
3640
3641
3642
3643
3644
3645
3646
3647
3648
3649
3650
3651
3652
3653
3654
3655
3656
3657
3658
3659
Definition
<complexType name="RegistryQueryType">
<complexContent>
<extension base="tns:RegistryEntryQueryType">
<sequence>
<element ref="tns:RegistryFilter" minOccurs="0" maxOccurs="1" />
</sequence>
</extension>
</complexContent>
</complexType>
<element name="RegistryQuery" type="tns:RegistryQueryType" />
<element name = "RegistryQueryResult">
<complexType>
<choice minOccurs = "0" maxOccurs = "unbounded">
<element ref = "rim:ObjectRef"/>
<element ref = "rim:RegistryObject"/>
<element ref = "rim:RegistryEntry"/>
<element ref = "rim:Registry"/>
Copyright © OASIS, 2002. All Rights Reserved
Page 104 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
3660
3661
3662
3663
</choice>
</complexType>
</element>
3664
Semantic Rules
3665
3666
1. Let R denote the set of all persistent Registry instances in the Registry. The following steps
will eliminate instances in R that do not satisfy the conditions of the specified filters.
3667
a) If R is empty then continue to the next numbered rule.
3668
3669
3670
b) If a RegistryFilter is not specified then go to the next step; otherwise, let x be a registry in
R. If x does not satisfy the RegistryFilter, then remove x from R. If R is empty then
continue to the next numbered rule.
3671
3672
c) Let R be the set of remaining Registry instances. Evaluate inherited RegistryEntryQuery
over R as explained in Section.
3673
3674
2. If R is empty, then raise the warning: registry query result is empty; otherwise, set R to be the
result of the RegistryQuery.
3675
3676
3. Return the result and any accumulated warnings or exceptions (in the RegistryErrorList)
within the RegistryResponse.
3677
8.2.15 SubscriptionQuery
3678
Purpose
3679
To identify a set of subscription instances as the result of a query over selected registry metadata.
3680
ebRIM Binding
Subscription
Registry
Object
3681
Figure 45: ebRIM Binding for SubscriptionQuery
3682
3683
3684
3685
3686
3687
3688
3689
3690
3691
3692
3693
3694
Definition
<complexType name = "SubscriptionQueryType">
<complexContent>
<extension base = "tns:RegistryObjectQueryType">
<sequence>
<element ref = "tns: SubscriptionFilter" minOccurs = "0" maxOccurs = "1"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name = "SubscriptionQuery" type = "tns: SubscriptionQueryType"/>
Copyright © OASIS, 2002. All Rights Reserved
Page 105 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
3695
3696
3697
3698
3699
3700
3701
3702
3703
3704
3705
<element name="SubscriptionQueryResult">
<complexType>
<choice minOccurs="0" maxOccurs="unbounded">
<element ref="rim:ObjectRef" />
<element ref="rim:RegistryObject" />
<element ref="rim: Subscription" />
</choice>
</complexType>
</element>
3706
Semantic Rules
3707
3708
1. Let S denote the set of all persistent Subscription instances in the Registry. The following
steps will eliminate instances in S that do not satisfy the conditions of the specified filters.
3709
a) If S is empty then continue to the next numbered rule.
3710
3711
3712
3713
b) If a SubscriptionFilter element is not directly contained in the SubscriptionQuery
element, then go to the next step; otherwise let x be a subscription instance in S. If x does
not satisfy the SubscriptionFilter then remove x from S. If S is empty then continue to the
next numbered rule.
3714
3715
c) Let S be the set of remaining Subscription instances. Evaluate inherited
RegistryObjectQuery over S as explained in Section.
3716
3717
2. If S is empty, then raise the warning: subscription query result is empty; otherwise, set S to
be the result of the SubscriptionQuery.
3718
3719
3. Return the result and any accumulated warnings or exceptions (in the RegistryErrorList)
within the RegistryResponse.
3720
3721
8.2.16 UserQuery
3722
Purpose
3723
To identify a set of user instances as the result of a query over selected registry metadata.
3724
3725
ebRIM Binding
3726
User
3727
Registry
Object
3728
3729
3730
PersonName
Postal
Address
3731
3732
3733
Telephone
Number
Email
Address
Figure 46: ebRIM Binding for OrganizationQuery Add PersonName under User and line up
Copyright © OASIS, 2002. All Rights Reserved
Page 106 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
3734
3735
3736
3737
3738
3739
3740
3741
3742
3743
3744
3745
3746
3747
3748
3749
3750
3751
3752
3753
3754
3755
3756
3757
3758
3759
3760
Definition
3761
Semantic Rules
3762
3763
1. Let U denote the set of all persistent User instances in the Registry. The following steps will
eliminate instances in U that do not satisfy the conditions of the specified filters.
<complexType name = "UserQueryType">
<complexContent>
<extension base = "tns:RegistryObjectQueryType">
<sequence>
<element ref = "tns:UserFilter" minOccurs = "0" maxOccurs="1"/>
<element ref = "tns:EmailAddressFilter" minOccurs = "0" maxOccurs="unbounded"/>
<element ref = "tns:PostalAddressFilter" minOccurs = "0" maxOccurs="1"/>
<element ref = "tns:PersonNameFilter" minOccurs = "0" maxOccurs="1"/>
<element ref = "tns:TelephoneNumberFilter" minOccurs = "0" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType >
<element name = "UserQuery" type = "tns:UserQueryType"/>
<element name = "UserQueryResult">
<complexType>
<choice minOccurs = "0" maxOccurs = "unbounded">
<element ref = "rim:ObjectRef"/>
<element ref = "rim:RegistryObject"/>
<element ref = "rim:User"/>
</choice>
</complexType>
</element>
3764
a)
If U is empty then continue to the next numbered rule.
3765
3766
3767
b)
If an UserFilter element is not directly contained in the UserQuery element, then go to the
next step; otherwise let x be an user instance in U. If x does not satisfy the UserFilter then
remove x from U. If U is empty then continue to the next numbered rule.
3768
3769
3770
3771
c)
If a EmailAddressFilter element is not directly contained in the UserQuery element then
go to the next step; otherwise, let x be an user in U. If email address of x does not satisfy
the EmailAddressFilter then remove x from U. If U is empty then continue to the next
numbered rule.
3772
3773
3774
3775
d)
If a PostalAddressFilter element is not directly contained in the UserQuery element then
go to the next step; otherwise, let x be an user in U. If postal address of x does not satisfy
the PostalAddressFilter then remove x from U. If U is empty then continue to the next
numbered rule.
3776
3777
3778
3779
e)
If a PersonNameFilter element is not directly contained in the UserQuery element then go
to the next step; otherwise, let x be an user in U. If reson name of x does not satisfy the
PersonNameFilter then remove x from U. If U is empty then continue to the next
numbered rule.
Copyright © OASIS, 2002. All Rights Reserved
Page 107 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
3780
3781
3782
3783
f)
If no TelephoneNumberFilter element is directly contained in the UserQuery element
then go to the next step; otherwise, let x be an user in U. If any of the
TelephoneNumberFilters isn’t satisfied by all of the telephone numbers of x then remove
x from U. If U is empty then continue to the next numbered rule.
3784
3785
g)
Let U be the set of remaining User instances. Evaluate inherited RegistryObjectQuery
over U as explained in Section 8.2.2.
3786
3787
3788
3789
2.
If U is empty, then raise the warning: user query result is empty; otherwise set U to be the
result of the UserQuery.
Return the result and any accumulated warnings or exceptions (in the RegistryErrorList) within
the RegistryResponse.
3790
8.2.17 Registry Filters
3791
Purpose
3792
To identify a subset of the set of all persistent instances of a given registry class.
3793
3794
3795
3796
3797
3798
3799
3800
3801
3802
3803
3804
3805
3806
3807
3808
3809
3810
3811
3812
3813
3814
3815
3816
3817
3818
3819
3820
3821
3822
3823
3824
3825
3826
Definition
<complexType name="FilterType">
<sequence>
<element ref="tns:Clause" />
</sequence>
</complexType>
<element name="RegistryObjectFilter" type="tns:FilterType" />
<element name="RegistryEntryFilter" type="tns:FilterType" />
<element name="ExtrinsicObjectFilter" type="tns:FilterType" />
<element name="RegistryPackageFilter" type="tns:FilterType" />
<element name="OrganizationFilter" type="tns:FilterType" />
<element name="ClassificationNodeFilter" type="tns:FilterType" />
<element name="AssociationFilter" type="tns:FilterType" />
<element name="ClassificationFilter" type="tns:FilterType" />
<element name="ClassificationSchemeFilter" type="tns:FilterType" />
<element name="ExternalLinkFilter" type="tns:FilterType" />
<element name="ExternalIdentifierFilter" type="tns:FilterType" />
<element name="SlotFilter" type="tns:FilterType" />
<element name="AuditableEventFilter" type="tns:FilterType" />
<element name="UserFilter" type="tns:FilterType" />
<element name="SlotValueFilter" type="tns:FilterType" />
<element name="PostalAddressFilter" type="tns:FilterType" />
<element name="TelephoneNumberFilter" type="tns:FilterType" />
<element name="EmailAddressFilter" type="tns:FilterType" />
<element name="ServiceFilter" type="tns:FilterType" />
<element name="ServiceBindingFilter" type="tns:FilterType" />
<element name="SpecificationLinkFilter" type="tns:FilterType" />
<element name="LocalizedStringFilter" type="tns:FilterType" />
<element name="FederationFilter" type = "tns:FilterType"/>
<element name="PersonNameFilter" type = "tns:FilterType"/>
<element name="RegistryFilter" type = "tns:FilterType"/>
<element name="SubscriptionFilter" type = "tns:FilterType"/>
Copyright © OASIS, 2002. All Rights Reserved
Page 108 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
3827
Semantic Rules
3828
1.
The Clause element is defined in Section 8.2.18.
3829
3830
3831
3832
3833
2.
For every RegistryObjectFilter XML element, the leftArgument attribute of any containing
SimpleClause shall identify a public attribute of the RegistryObject UML class defined in
[ebRIM]. If not, raise exception: registry object attribute error. The RegistryObjectFilter
returns a set of identifiers for RegistryObject instances whose attribute values evaluate to
True for the Clause predicate.
3834
3835
3836
3837
3838
3.
For every RegistryEntryFilter XML element, the leftArgument attribute of any containing
SimpleClause shall identify a public attribute of the RegistryEntry UML class defined in
[ebRIM]. If not, raise exception: registry entry attribute error. The RegistryEntryFilter
returns a set of identifiers for RegistryEntry instances whose attribute values evaluate to True
for the Clause predicate.
3839
3840
3841
3842
3843
4.
For every ExtrinsicObjectFilter XML element, the leftArgument attribute of any containing
SimpleClause shall identify a public attribute of the ExtrinsicObject UML class defined in
[ebRIM]. If not, raise exception: extrinsic object attribute error. The ExtrinsicObjectFilter
returns a set of identifiers for ExtrinsicObject instances whose attribute values evaluate to
True for the Clause predicate.
3844
3845
3846
3847
3848
5.
For every RegistryPackageFilter XML element, the leftArgument attribute of any containing
SimpleClause shall identify a public attribute of the RegistryPackage UML class defined in
[ebRIM]. If not, raise exception: package attribute error. The RegistryPackageFilter returns
a set of identifiers for RegistryPackage instances whose attribute values evaluate to True for
the Clause predicate.
3849
3850
3851
3852
3853
6.
For every OrganizationFilter XML element, the leftArgument attribute of any containing
SimpleClause shall identify a public attribute of the Organization or PostalAddress UML
classes defined in [ebRIM]. If not, raise exception: organization attribute error. The
OrganizationFilter returns a set of identifiers for Organization instances whose attribute
values evaluate to True for the Clause predicate.
3854
3855
3856
3857
3858
3859
3860
7.
For every ClassificationNodeFilter XML element, the leftArgument attribute of any
containing SimpleClause shall identify a public attribute of the ClassificationNode UML
class defined in [ebRIM]. If not, raise exception: classification node attribute error. If the
leftAttribute is the visible attribute “path” then if stringPredicate of the StringClause is not
“Equal” then raise exception: classification node path attribute error. The
ClassificationNodeFilter returns a set of identifiers for ClassificationNode instances whose
attribute values evaluate to True for the Clause predicate.
3861
3862
3863
3864
3865
8.
For every AssociationFilter XML element, the leftArgument attribute of any containing
SimpleClause shall identify a public attribute of the Association UML class defined in
[ebRIM]. If not, raise exception: association attribute error. The AssociationFilter returns a
set of identifiers for Association instances whose attribute values evaluate to True for the
Clause predicate.
3866
3867
3868
3869
3870
9.
For every ClassificationFilter XML element, the leftArgument attribute of any containing
SimpleClause shall identify a public attribute of the Classification UML class defined in
[ebRIM]. If not, raise exception: classification attribute error. The ClassificationFilter
returns a set of identifiers for Classification instances whose attribute values evaluate to True
for the Clause predicate.
Copyright © OASIS, 2002. All Rights Reserved
Page 109 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
3871
3872
3873
3874
3875
10.
For every ClassificationSchemeFilter XML element, the leftArgument attribute of any
containing SimpleClause shall identify a public attribute of the ClassificationNode UML
class defined in [ebRIM]. If not, raise exception: classification scheme attribute error. The
ClassificationSchemeFilter returns a set of identifiers for ClassificationScheme instances
whose attribute values evaluate to True for the Clause predicate.
3876
3877
3878
3879
3880
11.
For every ExternalLinkFilter XML element, the leftArgument attribute of any containing
SimpleClause shall identify a public attribute of the ExternalLink UML class defined in
[ebRIM]. If not, raise exception: external link attribute error. The ExternalLinkFilter returns
a set of identifiers for ExternalLink instances whose attribute values evaluate to True for the
Clause predicate.
3881
3882
3883
3884
3885
12.
For every ExternalIdentiferFilter XML element, the leftArgument attribute of any containing
SimpleClause shall identify a public attribute of the ExternalIdentifier UML class defined in
[ebRIM]. If not, raise exception: external identifier attribute error. The
ExternalIdentifierFilter returns a set of identifiers for ExternalIdentifier instances whose
attribute values evaluate to True for the Clause predicate.
3886
3887
3888
3889
13.
For every SlotFilter XML element, the leftArgument attribute of any containing
SimpleClause shall identify a public attribute of the Slot UML class defined in [ebRIM]. If
not, raise exception: slot attribute error. The SlotFilter returns a set of identifiers for Slot
instances whose attribute values evaluate to True for the Clause predicate.
3890
3891
3892
3893
3894
14.
For every AuditableEventFilter XML element, the leftArgument attribute of any containing
SimpleClause shall identify a public attribute of the AuditableEvent UML class defined in
[ebRIM]. If not, raise exception: auditable event attribute error. The AuditableEventFilter
returns a set of identifiers for AuditableEvent instances whose attribute values evaluate to
True for the Clause predicate.
3895
3896
3897
3898
15.
For every UserFilter XML element, the leftArgument attribute of any containing
SimpleClause shall identify a public attribute of the User UML class defined in [ebRIM]. If
not, raise exception: user attribute error. The UserFilter returns a set of identifiers for User
instances whose attribute values evaluate to True for the Clause predicate.
3899
3900
3901
3902
3903
3904
3905
3906
16.
SlotValue is a derived, non-persistent class based on the Slot class from ebRIM. There is one
SlotValue instance for each “value” in the “values” list of a Slot instance. The visible
attribute of SlotValue is“value”. It is a character string. The dynamic instances of SlotValue
are derived from the “values” attribute defined in ebRIM for a Slot instance. For every
SlotValueFilter XML element, the leftArgument attribute of any containing SimpleClause
shall identify the “value” attribute of the SlotValue class just defined. If not, raise exception:
slot element attribute error. The SlotValueFilter returns a set of Slot instances whose “value”
attribute evaluates to True for the Clause predicate.
3907
3908
3909
3910
3911
17.
For every PostalAddressFilter XML element, the leftArgument attribute of any containing
SimpleClause shall identify a public attribute of the PostalAddress UML class defined in
[ebRIM]. If not, raise exception: postal address attribute error. The PostalAddressFilter
returns a set of identifiers for PostalAddress instances whose attribute values evaluate to True
for the Clause predicate.
Copyright © OASIS, 2002. All Rights Reserved
Page 110 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
3912
3913
3914
3915
3916
18.
For every TelephoneNumberFilter XML element, the leftArgument attribute of any
containing SimpleClause shall identify a public attribute of the TelephoneNumber UML
class defined in [ebRIM]. If not, raise exception: telephone number identity attribute error.
The TelephoneNumberFilter returns a set of identifiers for TelephoneNumber instances
whose attribute values evaluate to True for the Clause predicate.
3917
3918
3919
3920
3921
19.
For every EmailAddressFilter XML element, the leftArgument attribute of any containing
SimpleClause shall identify a public attribute of the EmailAddress UML class defined in
[ebRIM]. If not, raise exception: email address attribute error. The EmailAddressFilter
returns a set of identifiers for EmailAddresss instances whose attribute values evaluate to
True for the Clause predicate.
3922
3923
3924
3925
20.
For every ServiceFilter XML element, the leftArgument attribute of any containing
SimpleClause shall identify a public attribute of the Service UML class defined in [ebRIM].
If not, raise exception: service attribute error. The ServiceFilter returns a set of identifiers for
Service instances whose attribute values evaluate to True for the Clause predicate.
3926
3927
3928
3929
3930
21.
For every ServiceBindingFilter XML element, the leftArgument attribute of any containing
SimpleClause shall identify a public attribute of the ServiceBinding UML class defined in
[ebRIM]. If not, raise exception: service binding attribute error. The ServiceBindingFilter
returns a set of identifiers for ServiceBinding instances whose attribute values evaluate to
True for the Clause predicate.
3931
3932
3933
3934
3935
22.
For every SpecificationLinkFilter XML element, the leftArgument attribute of any
containing SimpleClause shall identify a public attribute of the SpecificationLink UML class
defined in [ebRIM]. If not, raise exception: specification link attribute error. The
SpecificationLinkFilter returns a set of identifiers for SpecificationLink instances whose
attribute values evaluate to True for the Clause predicate.
3936
3937
3938
3939
3940
23.
For every LocalizedStringFilter XML element, the leftArgument attribute of any containing
SimpleClause shall identify a public attribute of the LocalizedString UML class defined in
[ebRIM]. If not, raise exception: localized string attribute error. The LocalizedStringFilter
returns a set of identifiers for LocalizedString instances whose attribute values evaluate to
True for the Clause predicate.
3941
3942
3943
3944
3945
24.
For every FederationFilter XML element, the leftArgument attribute of any containing
SimpleClause shall identify a public attribute of the Federation UML class defined in
[ebRIM]. If not, raise exception: federation attribute error. The FederationFilter returns a set
of identifiers for Federation instances whose attribute values evaluate to True for the Clause
predicate.
3946
3947
3948
3949
3950
25.
For every PersonNameFilter XML element, the leftArgument attribute of any containing
SimpleClause shall identify a public attribute of the PersonName UML class defined in
[ebRIM]. If not, raise exception: person name attribute error. The PersonNameFilter returns
a set of identifiers for PersonName instances whose attribute values evaluate to True for the
Clause predicate.
3951
3952
3953
3954
26.
For every RegistryFilter XML element, the leftArgument attribute of any containing
SimpleClause shall identify a public attribute of the Registry UML class defined in [ebRIM].
If not, raise exception: registry attribute error. The RegistryFilter returns a set of identifiers
for Registry instances whose attribute values evaluate to True for the Clause predicate.
Copyright © OASIS, 2002. All Rights Reserved
Page 111 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
3955
3956
3957
3958
3959
27. For every SubscriptionFilter XML element, the leftArgument attribute of any containing
SimpleClause shall identify a public attribute of the Subscription UML class defined in
[ebRIM]. If not, raise exception: subscription attribute error. The SubscriptionFilter returns a
set of identifiers for Subscription instances whose attribute values evaluate to True for the
Clause predicate.
3960
8.2.18 XML Clause Constraint Representation
3961
Purpose
3962
3963
3964
The simple XML FilterQuery utilizes a formal XML structure based on Predicate Clauses.
Predicate Clauses are utilized to formally define the constraint mechanism, and are referred to
simply as Clauses in this specification.
3965
Conceptual Diagram
3966
The following is a conceptual diagram outlining the Clause structure.
3967
3968
3969
Figure 47: The Clause Structure
3970
Semantic Rules
3971
3972
3973
Predicates and Arguments are combined into a "LeftArgument - Predicate - RightArgument"
format to form a Clause. There are two types of Clauses: SimpleClauses and CompoundClauses.
3974
A SimpleClause always defines the leftArgument as a text string, sometimes referred to as the
SimpleClauses
Copyright © OASIS, 2002. All Rights Reserved
Page 112 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
3975
3976
3977
3978
3979
Subject of the Clause. SimpleClause itself is incomplete (abstract) and must be extended.
SimpleClause is extended to support BooleanClause, StringClause, and RationalClause
(abstract).
3980
3981
3982
3983
BooleanClause implicitly defines the predicate as ‘equal to’, with the right argument as a
boolean.
3984
3985
3986
StringClause defines the predicate as an enumerated attribute of appropriate string-compare
operations and a right argument as the element’s text data. String compare operations are defined
as follow:
BooleanClause
StringClauses
3987
3988
Contains: Evaluates to true if left argument contains the content of the StringClause.
Evaluates to false otherswise.
3989
3990
NotContains: Evaluates to true if left argument does not contain the content of the
StringClause. Evaluates to false otherswise.
3991
3992
StartsWith: Evaluates to true if left argument starts with the content of the StringClause.
Evaluates to false otherswise.
3993
3994
NotStartsWith: Evaluates to true if left argument does not start with the content of the
StringClause. Evaluates to false otherswise.
3995
3996
3997
3998
Like: Evaluates to true if left argument matches the pattern specified by the content of the
StringClause. Evaluates to false otherswise. The pattern for the Like operation is a subset of the LIKE syntax in SQL-92. The ‘*’ or ‘%’ character matches any number of
characters while the ‘?’ or ‘_’ character matches a single character.
3999
4000
NotLike: Evaluates to true if left argument does not match the pattern specified by the
content of the StringClause. Evaluates to false otherswise.
4001
4002
Equal: Evaluates to true if left argument is lexically equal to the content of the
StringClause. Evaluates to false otherswise.
4003
4004
NotEqual: Evaluates to true if left argument is lexically not equal to the content of the
StringClause. Evaluates to false otherswise.
4005
4006
EndsWith: Evaluates to true if left argument ends with the content of the StringClause.
Evaluates to false otherswise.
4007
4008
4009
4010
NotEndsWith: Evaluates to true if left argument does not end with the content of the
StringClause. Evaluates to false otherswise.
4011
4012
4013
4014
4015
RationalClauses
Rational number support is provided through a common RationalClause providing an
enumeration of appropriate rational number compare operations, which is further extended to
IntClause and FloatClause, each with appropriate signatures for the right argument.
CompoundClauses
Copyright © OASIS, 2002. All Rights Reserved
Page 113 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
4016
4017
A CompoundClause contains two or more Clauses (Simple or Compound) and a connective
predicate. This provides for arbitrarily complex Clauses to be formed.
4018
4019
4020
4021
4022
4023
4024
4025
4026
4027
4028
4029
4030
4031
4032
4033
4034
4035
4036
4037
4038
4039
4040
4041
4042
4043
4044
4045
4046
4047
4048
4049
4050
4051
4052
4053
4054
4055
4056
4057
4058
4059
4060
4061
4062
4063
4064
4065
4066
4067
4068
4069
4070
4071
Definition
<element name = "Clause">
<annotation>
<documentation xml:lang = "en">
The following lines define the XML syntax for Clause.
</documentation>
</annotation>
<complexType>
<choice>
<element ref = "tns:SimpleClause"/>
<element ref = "tns:CompoundClause"/>
</choice>
</complexType>
</element>
<element name = "SimpleClause">
<complexType>
<choice>
<element ref = "tns:BooleanClause"/>
<element ref = "tns:RationalClause"/>
<element ref = "tns:StringClause"/>
</choice>
<attribute name = "leftArgument" use = "required" type = "string"/>
</complexType>
</element>
<element name = "CompoundClause">
<complexType>
<sequence>
<element ref = "tns:Clause" maxOccurs = "unbounded"/>
</sequence>
<attribute name = "connectivePredicate" use = "required">
<simpleType>
<restriction base = "NMTOKEN">
<enumeration value = "And"/>
<enumeration value = "Or"/>
</restriction>
</simpleType>
</attribute>
</complexType>
</element>
<element name = "BooleanClause">
<complexType>
<attribute name = "booleanPredicate" use = "required" type = "boolean"/>
</complexType>
</element>
<element name = "RationalClause">
<complexType>
<choice>
<element ref = "tns:IntClause"/>
<element ref = "tns:FloatClause"/>
<element ref = "tns:DateTimeClause"/>
</choice>
<attribute name = "logicalPredicate" use = "required">
Copyright © OASIS, 2002. All Rights Reserved
Page 114 of 188
OASIS/ebXML Registry Services Specification v3.0
4072
4073
4074
4075
4076
4077
4078
4079
4080
4081
4082
4083
4084
4085
4086
4087
4088
4089
4090
4091
4092
4093
4094
4095
4096
4097
4098
4099
4100
4101
4102
4103
4104
4105
4106
4107
4108
4109
4110
4111
4112
July 2017
<simpleType>
<restriction base = "NMTOKEN">
<enumeration value = "LE"/>
<enumeration value = "LT"/>
<enumeration value = "GE"/>
<enumeration value = "GT"/>
<enumeration value = "EQ"/>
<enumeration value = "NE"/>
</restriction>
</simpleType>
</attribute>
</complexType>
</element>
<element name = "IntClause" type = "integer"/>
<element name = "FloatClause" type = "float"/>
<element name = "DateTimeClause" type = "dateTime"/>
<element name = "StringClause">
<complexType>
<simpleContent>
<extension base = "string">
<attribute name = "stringPredicate" use = "required">
<simpleType>
<restriction base = "NMTOKEN">
<enumeration value = "Contains"/>
<enumeration value = "NotContains"/>
<enumeration value = "StartsWith"/>
<enumeration value = "NotStartsWith"/>
<enumeration value = "Like"/>
<enumeration value = "Equal"/>
<enumeration value = "NotEqual"/>
<enumeration value = "EndsWith"/>
<enumeration value = "NotEndsWith"/>
</restriction>
</simpleType>
</attribute>
</extension>
</simpleContent>
</complexType>
</element>
4113
Examples
4114
4115
4116
4117
4118
4119
4120
4121
4122
4123
4124
Simple BooleanClause: "Smoker" = True
4125
Simple StringClause: "Smoker" contains "mo"
<Clause>
<SimpleClause leftArgument="Smoker">
<BooleanClause booleanPredicate="True"/>
</SimpleClause>
</Clause>
<BooleanClause param="sqlQuerySupported" operation="Equals”>
<value>true</value>
</BooleanClause>
Copyright © OASIS, 2002. All Rights Reserved
Page 115 of 188
OASIS/ebXML Registry Services Specification v3.0
4126
4127
4128
4129
4130
4131
July 2017
<Clause>
<SimpleClause leftArgument = "Smoker">
<StringClause stringPredicate = "Contains">mo</StringClause>
</SimpleClause>
<Clause>
4132
4133
4134
4135
4136
4137
4138
4139
4140
4141
Simple IntClause: "Age" >= 7
4142
4143
4144
4145
4146
4147
4148
4149
4150
4151
Simple FloatClause: "Size" = 4.3
4152
4153
4154
4155
4156
4157
4158
4159
4160
4161
4162
4163
4164
4165
4166
4167
4168
4169
4170
Compound with two Simples (("Smoker" = False)AND("Age" =< 45))
4171
Coumpound with one Simple and one Compound
4172
4173
4174
4175
4176
4177
( ("Smoker" = False)And(("Age" =< 45)Or("American"=True)) )
<Clause>
<SimpleClause leftArgument="Age">
<RationalClause logicalPredicate="GE">
<IntClause>7</IntClause>
</RationalClause>
</SimpleClause>
</Clause>
<Clause>
<SimpleClause leftArgument="Size">
<RationalClause logicalPredicate="Equal">
<FloatClause>4.3</FloatClause>
</RationalClause>
</SimpleClause>
</Clause>
<Clause>
<CompoundClause connectivePredicate="And">
<Clause>
<SimpleClause leftArgument="Smoker">
<BooleanClause booleanPredicate="False"/>
</SimpleClause>
</Clause>
<Clause>
<SimpleClause leftArgument="Age">
<RationalClause logicalPredicate="LE">
<IntClause>45</IntClause>
</RationalClause>
</SimpleClause>
</Clause>
</CompoundClause>
</Clause>
<Clause>
<CompoundClause connectivePredicate="And">
<Clause>
<SimpleClause leftArgument="Smoker">
Copyright © OASIS, 2002. All Rights Reserved
Page 116 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
4178
4179
4180
4181
4182
4183
4184
4185
4186
4187
4188
4189
4190
4191
4192
4193
4194
4195
4196
4197
4198
4199
<BooleanClause booleanPredicate="False"/>
</SimpleClause>
</Clause>
<Clause>
<CompoundClause connectivePredicate="Or">
<Clause>
<SimpleClause leftArgument="Age">
<RationalClause logicalPredicate="LE">
<IntClause>45</IntClause>
</RationalClause>
</SimpleClause>
</Clause>
<Clause>
<SimpleClause leftArgument="American">
<BooleanClause booleanPredicate="True"/>
</SimpleClause>
</Clause>
</CompoundClause>
</Clause>
</CompoundClause>
<Clause>
4200
8.3 SQL Query Support
4201
4202
4203
4204
The Registry may optionally support an SQL based query capability that is designed for Registry
clients that demand more advanced query capability. The optional SQLQuery element in the
AdhocQueryRequest allows a client to submit complex SQL queries using a declarative query
language.
4205
4206
4207
4208
4209
4210
The syntax for the SQLQuery of the Registry is defined by a stylized use of a proper subset of
the “SELECT” statement of Entry level SQL defined by ISO/IEC 9075:1992, Database
Language SQL [SQL], extended to include <sql invoked routines> (also known as
stored procedures) as specified in ISO/IEC 9075-4 [SQL-PSM] and pre-defined routines defined
in template form in Appendix D.3. The syntax of the Registry query language is defined by the
BNF grammar in D.1.
4211
4212
Note that the use of a subset of SQL syntax for SQLQuery does not imply a requirement to use
relational databases in a Registry implementation.
4213
8.3.1 SQL Query Syntax Binding To [ebRIM]
4214
4215
4216
SQL Queries are defined based upon the query syntax in in Appendix D.1 and a fixed relational
schema defined in Appendix D.3. The relational schema is an algorithmic binding to [ebRIM] as
described in the following sections.
4217
Class Binding
4218
4219
4220
A subset of the class names defined in [ebRIM] map to table names that may be queried by an
SQL query. Appendix D.3 defines the names of the ebRIM classes that may be queried by an
SQL query.
4221
4222
The algorithm used to define the binding of [ebRIM] classes to table definitions in Appendix D.3
is as follows:
Copyright © OASIS, 2002. All Rights Reserved
Page 117 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
4223
4224
4225
4226
4227
4228
4229
4230
4231
4232
4233
4234
4235
An SQLQuery against a table not defined in Appendix D.3 may raise an error condition:
InvalidQueryException.
4236
4237
The following sections describe the algorithm for mapping attributes of [ebRIM] to SQLcolumn
definitions.
4238
Primitive Attributes Binding
4239
4240
4241
4242
4243
Attributes defined by [ebRIM] that are of primitive types (e.g. String) may be used in the same
way as column names in SQL. Again the exact attribute names are defined in the class
definitions in [ebRIM]. Note that while names are in mixed case, SQL-92 is case insensitive. It is
therefore valid for a query to contain attribute names that do not exactly match the case defined
in [ebRIM].
4244
Reference Attribute Binding
4245
4246
4247
A few of the [ebRIM] class attributes are of type ObjectRef and are a reference to an instance of
a class defined by [ebRIM]. For example, the sourceObject attribute of the Association class
returns a reference to an instance of a RegistryObject.
4248
4249
4250
In such cases the reference maps to the id attribute for the referenced object. The name of the
resulting column is the same as the attribute name in [ebRIM] as defined by 0. The data type for
the column is VARCHAR(64) as defined in Appendix D.3.
4251
4252
4253
When a reference attribute value holds a null reference, it maps to a null value in the SQL
binding and may be tested with the <null specification> (“IS [NOT] NULL” syntax) as defined
by [SQL].
4254
Reference attribute binding is a special case of a primitive attribute mapping.
4255
Complex Attribute Binding
4256
4257
4258
A few of the [ebRIM] interfaces define attributes that are not primitive types. Instead they are of
a complex type as defined by an entity class in [ebRIM]. Examples include attributes of type
TelephoneNumber, Contact, PersonName etc. in class Organization and class User.
Classes that have concrete instances are mapped to relational tables. In addition entity classes
(e.g. PostalAddress and TelephoneNumber) are also mapped to relational tables.
The intermediate classes in the inheritance hierarchy, namely RegistryObject and
RegistryEntry, map to relational views.
The names of relational tables and views are the same as the corresponding [ebRIM] class
name. However, the name binding is case insensitive.
Each [ebRIM] class that maps to a table in Appendix D.3 includes column definitions in
Appendix D.3 where the column definitions are based on a subset of attributes defined for
that class in [ebRIM]. The attributes that map to columns include the inherited attributes for
the [ebRIM] class. Comments in Appendix D.3 indicate which ancestor class contributed
which column definitions.
Copyright © OASIS, 2002. All Rights Reserved
Page 118 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
4259
4260
4261
4262
4263
4264
The SQL query schema does not map complex attributes as columns in the table for the class for
which the attribute is defined. Instead the complex attributes are mapped to columns in the table
for the domain class that represents the data type for the complex attribute (e.g.
TelephoneNumber). A column links the row in the domain table to the row in the parent table
(e.g. User). An additional column named ‘attribute_name’ identifies the attribute name in the
parent class, in case there are multiple attributes with the same complex attribute type.
4265
4266
4267
4268
This mapping also easily allows for attributes that are a collection of a complex type. For
example, a User may have a collection of TelephoneNumbers. This maps to multiple rows in the
TelephoneNumber table (one for each TelephoneNumber) where each row has a parent identifier
and an attribute_name.
4269
Binding of Methods Returning Collections
4270
4271
4272
4273
Several of the [ebRIM] classes define methods in addition to attributes, where these methods
return collections of references to instances of classes defined by [ebRIM]. For example, the
getPackages method of the RegistryObject class returns a Collection of references to instances of
Packages that the object is a member of.
4274
4275
4276
Such collection returning methods in [ebRIM] classes have been mapped to stored procedures in
Appendix D.3 such that these stored procedures return a collection of id attribute values. The
returned value of these stored procedures can be treated as the result of a table sub-query in SQL.
4277
4278
These stored procedures may be used as the right-hand-side of an SQL IN clause to test for
membership of an object in such collections of references.
4279
8.3.2 Semantic Constraints On Query Syntax
4280
4281
4282
This section defines simplifying constraints on the query syntax that cannot be expressed in the
BNF for the query syntax. These constraints must be applied in the semantic analysis of the
query.
4283
1. Class names and attribute names must be processed in a case insensitive manner.
4284
4285
2. The syntax used for stored procedure invocation must be consistent with the syntax of an
SQL procedure invocation as specified by ISO/IEC 9075-4 [SQL/PSM].
4286
4287
3. For this version of the specification, the SQL select column list consists of exactly one
column, and must always be t.id, where t is a table reference in the FROM clause.
4288
8.3.3 SQL Query Results
4289
4290
4291
4292
4293
4294
The result of an SQL query resolves to a collection of objects within the registry. It never
resolves to partial attributes. The objects related to the result set may be returned as an
ObjectRef, RegistryObject, RegistryEntry or leaf ebRIM class depending upon the returnType
attribute of the responseOption parameter specified by the client on the AdHocQueryRequest.
The entire result set is returned as a SQLQueryResult as defined by the AdHocQueryResponse in
Section 8.1.
4295
8.3.4 Simple Metadata Based Queries
4296
The simplest form of an SQL query is based upon metadata attributes specified for a single class
Copyright © OASIS, 2002. All Rights Reserved
Page 119 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
4297
within [ebRIM]. This section gives some examples of simple metadata based queries.
4298
4299
4300
4301
4302
4303
4304
4305
For example, to retrieve the collection of ExtrinsicObjects whose name contains the word
‘Acme’ and that have a version greater than 1.3, the following query must be submitted:
4306
4307
Note that the query syntax allows for conjugation of simpler predicates into more complex
queries as shown in the simple example above.
4308
8.3.5 RegistryObject Queries
4309
4310
4311
The schema for the SQL query defines a view called RegistryObject that allows doing a
polymorphic query against all RegistryObject instances regardless of their actual concrete type or
table name.
4312
4313
4314
4315
4316
4317
4318
4319
4320
The following example is similar to the example in Section 8.3.4 except that it is applied against
all RegistryObject instances rather than just ExtrinsicObject instances. The result set will include
id for all qualifying RegistryObject instances whose name contains the word ‘Acme’ and whose
description contains the word “bicycle”.
4321
8.3.6 RegistryEntry Queries
4322
4323
4324
The schema for the SQL query defines a view called RegistryEntry that allows doing a
polymorphic query against all RegistryEntry instances regardless of their actual concrete type or
table name.
4325
4326
4327
4328
4329
4330
4331
4332
4333
4334
The following example is the same as the example in Section 8.3.4 except that it is applied
against all RegistryEntry instances rather than just ExtrinsicObject instances. The result set will
include id for all qualifying RegistryEntry instances whose name contains the word ‘Acme’ and
that have a version greater than 1.3.
4335
8.3.7 Classification Queries
4336
This section describes various classification related queries.
4337
Identifying ClassificationNodes
4338
4339
4340
4341
ClassificationNodes are identified by their “id” attribute, as are all objects in [ebRIM]. However,
they may also be identified by their a “path” attribute that specifies an XPATH expression [XPT]
from a root classification node to the specified classification node in the XML document that
would represent the ClassificationNode tree including the said ClassificationNode.
SELECT eo.id from ExtrinsicObject eo, Name nm where nm.value LIKE '%Acme%' AND
eo.id = nm.parent AND
eo.majorVersion >= 1 AND
(eo.majorVersion >= 2 OR eo.minorVersion > 3);
SELECT ro.id from RegistryObject ro, Name nm, Description d where nm.value LIKE '%Acme%' AND
d.value LIKE '%bicycle%' AND
ro.id = nm.parent AND ro.id = d.parent;
SELECT re.id from RegistryEntry re, Name nm where nm.value LIKE '%Acme%' AND
re.id = nm.parent AND
re.majorVersion >= 1 AND
(re.majorVersion >= 2 OR re.minorVersion > 3);
Copyright © OASIS, 2002. All Rights Reserved
Page 120 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
4342
Retrieving ClassificationSchemes
4343
4344
4345
4346
The following query retrieves the collection of ClassificationSchemes :
4347
4348
The above query returns all ClassificationSchemes. Note that the above query may also specify
additional predicates (e.g. name, description etc.) if desired.
4349
Retrieving Children of Specified ClassificationNode
4350
4351
4352
4353
4354
The following query retrieves the children of a ClassificationNode given the “id” attribute of that
node:
4355
4356
The above query returns all ClassificationNodes that have the node specified by <id> as their
parent attribute.
4357
Retrieving Objects Classified By a ClassificationNode
4358
4359
4360
4361
4362
4363
4364
4365
4366
4367
4368
4369
4370
4371
4372
The following query retrieves the collection of ExtrinsicObjects classified by specified
ClassificationNodes:
4373
4374
4375
4376
The above query retrieves the collection of ExtrinsicObjects that are classified by the
Automotive Industry and the Japan Geography. Note that according to the semantics defined for
GetClassifiedObjectsRequest, the query will also contain any objects that are classified by
descendents of the specified ClassificationNodes.
4377
Retrieving Classifications That Classify an Object
4378
4379
4380
4381
4382
The following query retrieves the collection of Classifications that classify a specified Object:
4383
8.3.8 Association Queries
4384
This section describes various Association related queries.
4385
Retrieving All Association With Specified Object As Its Source
4386
4387
4388
The following query retrieves the collection of Associations that have the specified Object as its
source:
SELECT scheme.id FROM ClassificationScheme scheme;
SELECT cn.id FROM ClassificationNode cn WHERE parent = <id>
SELECT id FROM ExtrinsicObject
WHERE
id IN (SELECT classifiedObject FROM Classification
WHERE
classificationNode IN (SELECT id FROM ClassificationNode
WHERE path = “/Geography/Asia/Japan’))
AND
id IN (SELECT classifiedObject FROM Classification
WHERE
classificationNode IN (SELECT id FROM ClassificationNode
WHERE path = ‘/Industry/Automotive’))
SELECT id FROM Classification c
WHERE c.classifiedObject = <id>;
Copyright © OASIS, 2002. All Rights Reserved
Page 121 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
4389
4390
SELECT id FROM Association WHERE sourceObject = <id>
4391
Retrieving All Association With Specified Object As Its Target
4392
4393
4394
4395
4396
The following query retrieves the collection of Associations that have the specified Object as its
target:
4397
Retrieving Associated Objects Based On Association Attributes
4398
4399
The following query retrieves the collection of Associations that have specified Association
attributes:
4400
4401
4402
4403
Select Associations that have the specified name.
4404
4405
4406
4407
4408
4409
Select Associations that have the specified association type, where association type is a string
containing the corresponding field name described in [ebRIM].
4410
Complex Association Queries
4411
4412
4413
4414
4415
4416
4417
4418
4419
The various forms of Association queries may be combined into complex predicates. The
following query selects Associations that have a specific sourceObject, targetObject and
associationType:
4420
8.3.9 Package Queries
4421
4422
4423
4424
The following query retrieves all Packages that a specified RegistryObject belongs to:
4425
Complex Package Queries
4426
4427
4428
4429
4430
4431
4432
4433
The following query retrieves all Packages that a specified object belongs to, that are not
deprecated and where name contains "RosettaNet."
4434
8.3.10 ExternalLink Queries
4435
The following query retrieves all ExternalLinks that a specified ExtrinsicObject is linked to:
SELECT id FROM Association WHERE targetObject = <id>
SELECT id FROM Association WHERE name = <name>
SELECT id FROM Association WHERE
associationType = <associationType>
SELECT id FROM Association WHERE
sourceObject = <id1> AND
targetObject = <id2> AND
associationType = <associationType>;
SELECT id FROM Package WHERE id IN (RegistryObject_registryPackages(<id>));
SELECT id FROM Package p, Name n WHERE
p.id IN (RegistryObject_registryPackages(<id>)) AND
nm.value LIKE '%RosettaNet%' AND nm.parent = p.id AND
p.status <> ‘Deprecated’
Copyright © OASIS, 2002. All Rights Reserved
Page 122 of 188
OASIS/ebXML Registry Services Specification v3.0
4436
4437
4438
July 2017
SELECT id From ExternalLink WHERE id IN (RegistryObject_externalLinks(<id>))
4439
4440
4441
4442
The following query retrieves all ExtrinsicObjects that are linked by a specified ExternalLink:
4443
Complex ExternalLink Queries
4444
4445
4446
4447
4448
4449
4450
4451
The following query retrieves all ExternalLinks that a specified ExtrinsicObject belongs to, that
contain the word ‘legal’ in their description and have a URL for their externalURI.
4452
8.3.11 Audit Trail Queries
4453
4454
4455
4456
The following query retrieves all the AuditableEvents for a specified RegistryObject:
4457
8.3.12 Object Export Queries
4458
The standard Ad hoc Query protocol may be used to export RegistryObjects from a registry.
4459
Export Objects Owned By Specified User
4460
4461
4462
4463
4464
4465
4466
The following query retieves all RegistryObjects for a specified User id:
4467
Export Objects Owned By Users Affiliated With Specified Organization
4468
4469
4470
4471
4472
4473
4474
4475
4476
The following query retieves all RegistryObjects that are owned by any User that is affiliated
with the Organization matching the specied name pattern:
4477
8.4 Content Retrieval
4478
4479
4480
4481
A client retrieves content via the Registry by sending the GetContentRequest to the
QueryManager. The GetContentRequest specifies a list of ObjectRefs for Objects that need to be
retrieved. The QueryManager returns the specified content by sending a GetContentResponse
message to the RegistryClient interface of the client.
4482
If there are no errors encountered, the GetContentResponse message includes the specified
SELECT id From ExtrinsicObject WHERE id IN (RegistryObject_linkedObjects(<id>))
SELECT id FROM ExternalLink WHERE
id IN (RegistryObject_externalLinks(<id>)) AND
description LIKE ‘%legal%’ AND
externalURI LIKE ‘%http://%’
SELECT id FROM AuditableEvent WHERE registryObject = <id>
SELECT * from RegistryObject ro, AuditableEvent ae, User u WHERE
ae.user_ = <userId> AND
ae.eventType = 'Created' AND
ae.registryObject = ro.id
SELECT * from RegistryObject ro, AuditableEvent ae, User u WHERE
ae.user_ = u.id AND ae.eventType = 'Created' AND ae.registryObject = ro.id AND
u.id IN (
SELECT u1.id from User u1, Organization o, Name n WHERE
n.value LIKE '%Sun%' AND u1.organization = o.id AND n.parent = o.id
)
Copyright © OASIS, 2002. All Rights Reserved
Page 123 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
4483
content(s) as mime multipart attachment(s) within the message.
4484
4485
If there are errors encountered, the RegistryResponse payload includes the errors and there are
no additional mime multipart attachments.
4486
4487
Figure 48: Content Retrieval Sequence Diagram
4488
8.4.1 GetContentRequest
4489
The GetContentRequest is used to retrieve repository item content from the registry.
4490
Syntax:
4491
4492
Figure 49: GetContentRequest Syntax
4493
Parameters:
4494
4495
4496
ObjectRefList: This parameter specifies a collection of ObjectRef elements that
specify references to the ExtrinsicObjects whose corresponding repository items
are being retrieved.
4497
4498
Returns:
4499
This request returns a GetContentResponse. See section 8.4.2 for details.
Copyright © OASIS, 2002. All Rights Reserved
Page 124 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
4500
Exceptions:
4501
In addition to the exceptions common to all requests, the following exceptions may be returned:
4502
4503
ObjectNotFoundException: signifies that one or more ObjectRef elements in the
ObjectRefList did not match any objects in the registry.
4504
8.4.2 GetContentResponse
4505
The GetContentResponse is sent by the registry as a response to GetContentRequest.
4506
4507
Syntax:
4508
4509
Figure 50: GetContentResponse Syntax
4510
Parameters:
4511
4512
The GetContentResponse does not define any new parameters beyond those inherited by
RegistryResponseType as defined in 6.9.2.
4513
8.4.3 Identification Of Content Payloads
4514
4515
4516
4517
4518
4519
4520
4521
Since the GetContentResponse message may include several repository items as additional
payloads, it is necessary to have a way to identify each mime multipart attachment in the
message. To facilitate this identification, the Registry must do the following:
Use the “id” attribute of the ExtrinsicObject instance as the value of the Content-ID header
parameter for the mime multipart that contains the corresponding repository item for the
ExtrinsicObject.
In case of [ebMS] transport, use the “id” attribute of the ExtrinsicObject instance in the
Reference element for that object in the Manifest element of the ebXMLHeader.
4522
8.4.4 GetContentResponse Message Structure
4523
4524
4525
4526
4527
4528
4529
4530
4531
4532
The following message fragment illustrates the structure of the GetContentResponse Message
that is returning a Collection of Collaboration Protocol Profiles as a result of a
GetContentRequest that specified the “id” attributes for the requested objects. Note that the
boundary parameter in the Content-Type headers in the example below are meant to be
illustrative not prescriptive.
Content-type: multipart/related; boundary="MIME_boundary"; type="text/xml";
--MIME_boundary
Content-ID: <[email protected]>
Copyright © OASIS, 2002. All Rights Reserved
Page 125 of 188
OASIS/ebXML Registry Services Specification v3.0
4533
4534
4535
4536
4537
4538
4539
4540
4541
4542
4543
4544
4545
4546
4547
4548
4549
4550
4551
4552
4553
4554
4555
4556
4557
4558
4559
4560
4561
4562
4563
4564
4565
4566
4567
4568
4569
4570
4571
4572
4573
4574
4575
4576
4577
4578
4579
4580
4581
4582
4583
4584
4585
4586
4587
4588
4589
4590
4591
4592
4593
4594
4595
4596
4597
4598
4599
4600
4601
4602
4603
4604
4605
July 2017
Content-Type: text/xml
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV='http://schemas.xmlsoap.org/soap/envelope/'
xmlns:eb= 'http://www.oasis-open.org/committees/ebxml-msg/schema/draft-msg-header-03.xsd'>
<SOAP-ENV:Header>
<!--ebMS header goes here if using ebMS-->
...
<ds:Signature ...>
<!--signature over soap envelope-->
...
</ds:Signature>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<!--ebMS manifest goes here if using ebMS-->
...
<?xml version="1.0" encoding="UTF-8"?>
<GetContentResponse>
<ObjectRefList>
<ObjectRef id="urn:uuid:d8163dfb-f45a-4798-81d9-88aca29c24ff"/>
<ObjectRef id="urn:uuid:212c3a78-1368-45d7-acc9-a935197e1e4f"/>
</ObjectRefList>
</GetContentResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
--MIME_boundary
Content-ID: urn:uuid:d8163dfb-f45a-4798-81d9-88aca29c24ff
Content-Type: Multipart/Related; boundary=payload1_boundary; type=text/xml
Content-Description: Optionally describe payload1 here
--payload1_boundary
Content-Type: text/xml; charset=UTF-8
Content-ID: signature:urn:uuid:d8163dfb-f45a-4798-81d9-88aca29c24ff
<ds:Signature ...>
... Signature for payload1
</ds:Signature>
--payload1_boundary
Content-ID: urn:uuid:d8163dfb-f45a-4798-81d9-88aca29c24ff
Content-Type: text/xml
<?xml version="1.0" encoding="UTF-8"?>
<tp:CollaborationProtocolProfile ...>
.....
</tp:CollaborationProtocolProfile>
--payload1_boundary---MIME_boundary
Content-ID: urn:uuid:212c3a78-1368-45d7-acc9-a935197e1e4f
Content-Type: Multipart/Related; boundary=payload2_boundary; type=text/xml
Content-Description: Optionally describe payload2 here
--payload2_boundary
Content-Type: text/xml; charset=UTF-8
Content-ID: signature:urn:uuid:212c3a78-1368-45d7-acc9-a935197e1e4f
<ds:Signature ...>
... Signature for payload2
</ds:Signature>
--payload2_boundary
Content-ID: urn:uuid:212c3a78-1368-45d7-acc9-a935197e1e4f
Copyright © OASIS, 2002. All Rights Reserved
Page 126 of 188
OASIS/ebXML Registry Services Specification v3.0
4606
4607
4608
4609
4610
4611
4612
4613
4614
4615
4616
4617
July 2017
Content-Type: text/xml
<?xml version="1.0" encoding="UTF-8"?>
<tp:CollaborationProtocolProfile ...>
.....
</tp:CollaborationProtocolProfile>
--payload2_boundary---MIME_boundary--
Copyright © OASIS, 2002. All Rights Reserved
Page 127 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
4618
9 Content Management Services
4619
4620
4621
4622
4623
This chapter describes the Content Management services of the ebXML Registry. Examples of
Content Management Services include, but are not limited to, content validation and content
cataloging. Content Management Services result in improved quality and integrity of registry
content and metadata as well as improved ability for clients to discover that content and
metadata.
4624
4625
4626
4627
The Content Management Services facility of the registry is based upon a pluggable architecture
that allows clients to publish and discover new Content Management Services as Service objects
that conform to a normative web service interface specified in this chapter. Clients may define a
Content Management Services that is specialized for managing a specific type of content.
4628
4629
4630
4631
The Content Management Services facility as a whole is an optional normative feature of
ebXML Registries compliant to version 3 or later of this specification. Note however that some
aspects of the Content Management Services facility are required normative features of ebXML
Registries.
4632
9.1 Content Validation
4633
4634
The Content Validation feature provides the ability to enforce validation rules upon submitted
content and metadata in a content specific manner.
Invocation Control File
Original
Content
Content
Validation
Service
Content +
Metadata
4635
4636
Success | Failure
Figure 51: Content Validation Service
4637
4638
4639
4640
A registry uses one or more Content Validation Services to automatically validate the
RegistryObjects and repository items when they are submitted to the registry. A registry must
reject a submission request in its entirety if it contains invalid data. In such cases a
ValidationException must be returned to the client.
4641
Content Validation feature improves the quality of data in the registry.
4642
9.1.1 Content Validation: Use Cases
4643
The following use cases illustrates use cases of the Content Validation feature:
4644
Validation of HL7 Conformance Profiles
4645
4646
4647
The Healthcare Standards organization HL7 uses content validation to enforce consistency rules
and semantic checks whenever an HL7 member submits an HL7 Conformance Profile. HL7 is
also planning to use the feature to improve the quality of other types of HL7 artifacts.
Copyright © OASIS, 2002. All Rights Reserved
Page 128 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
4648
Validation of Business Processes
4649
4650
4651
Content validation may be used to enforce consistency rules and semantic checks whenever a
Business Process is submitted to the registry. This feature may be used by organizations such as
UN/CEFACT, OAG, and RosettaNet.
4652
Validation of UBL Business Documents
4653
4654
Content validation may be used by the UBL technical committee to enforce consistency rules
and semantic checks whenever a UBL business document is submitted to the registry.
4655
9.2 Content Cataloging
4656
4657
4658
The Content Cataloging feature provides the ability to selectively convert submitted
RegistryObject and repository items into metadata defined by [ebRIM], in a content specific
manner.
Invocation Control File
Original
Content
Content
Cataloging
Service
Content +
Metadata
4659
4660
Cataloged
Content
Content +
Metadata
Figure 52: Content Cataloging Service
4661
4662
4663
4664
4665
4666
A registry uses one or more Content Cataloging Services to automatically catalog
RegistryObjects and repository items. Cataloging creates and/or updates RegistryObject
metadata such as ExtrinsicObject or Classification instances. The cataloged metadata enables
clients to discover the repository item based upon content from the repository item, using
standard query capabilities of the registry. This is referred to as Content-based Discovery.
The main benefit of the Content Cataloging feature is to enable Content-based Discovery.
4667
9.2.1 Content-based Discovery: Use Cases
4668
There are many scenarios where content-based discovery is necessary.
4669
Find All CPPs Where Role is “Buyer”
4670
4671
A company that sells a product using the RosettaNet PIP3A4 Purchase Order process wants to
find CPPs for other companies where the Role element of the CPP is that of “Buyer”.
4672
Find All XML Schema’s That Use Specified Namespace
4673
4674
A client may wish to discover all XML Schema documents in the registry that use an XML
namespace containing the word “oasis”.
Copyright © OASIS, 2002. All Rights Reserved
Page 129 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
4675
Find All WSDL Descriptions with a SOAP Binding
4676
4677
4678
An ebXML registry client is attempting to discover all repository items that are WSDL
descriptions that have a SOAP binding defined. Note that SOAP binding related information is
content within the WSDL document and not metadata.
4679
9.3 Abstract Content Management Service
4680
4681
4682
4683
4684
4685
4686
4687
4688
4689
4690
4691
4692
4693
4694
This section describes in abstract terms how the registry supports pluggable, user-defined
Content Management Services. A Content Management Service is invoked in response to
content being submitted to the registry via the standard Submit/UpdateObjectsRequest method.
The Service invocation is on a per request basis where one request may result in many
invocations, one for each RegistryObject for which a Content Management Service is configured
within the registry.
The registry may perform such invocation in one of two ways.
4695
9.3.1 Inline Invocation Model
4696
4697
4698
4699
4700
4701
4702
4703
4704
4705
4706
4707
4708
4709
4710
4711
4712
4713
4714
4715
4716
In an inline invocation model a registry must invoke a Content Management Service inline with
Submit/UpdateObjectsRequest processing and prior to committing the
Submit/UpdateObjectsRequest. All metadata and content from the original
Submit/UpdateObjectsRequest request or from the Content Management Service invocation
must be committed as an atomic transaction.
Figure 53 shows an abstract Content Management Service and how it is used by an ebXML
Registry using an inline invocation model. The steps are as follows:
Inline Invocation Model: Content Management Service may be invoked inline with the
processing of the Submit/UpdateObjectsRequest and prior to committing the content.
This is referred to as Inline Invocation Model.
De-coupled Invocation Model: Content Management Service may be invoked de-coupled
from the processing of the Submit/UpdateObjectsRequest and some time after
committing the content. This is referred to as De-coupled Invocation Model.
1. A client submits a Content Management Service S1 to an ebXML Registry. The client
typically belongs to an organization responsible for defining a specific type of content.
For example the client may belong to RosettaNet.org and submits a Content Validation
Service for validating RosettaNet PIPs. The client uses the standard
Submit/UpdateObjectsRequest interface to submit the Service. This is a one-time step to
configure this Content Management Service in the registry.
2. Once the Content Management Service has been submitted, a potentially different client
may submit content to the registry that is of the same object type for which the Content
Management Service has been submitted. The client uses the standard
Submit/UpdateObjectsRequest interface to submit the content.
3. The registry determines there is a Content Management Service S1 configured for the
object type for the content submitted. It invokes S1 using a
ContentManagementServiceRequest and passes it the content.
Copyright © OASIS, 2002. All Rights Reserved
Page 130 of 188
OASIS/ebXML Registry Services Specification v3.0
4717
4718
4719
4720
4721
4722
4723
4724
July 2017
4. The Content Management Service S1 processes the content and sends back a
ContentManagementServiceResponse.
5. The registry then commits the content to the registry if there are no errors encountered.
6. The registry returns a RegistryResponse to the client for the
Submit/UpdateObjectsRequest in step 2.
1. SubmitObjectRequest
Content +
Metadata
Service
2. SubmitObjectRequest
Registry Client
3. Content
Management
Service
Request
4725
4726
ebXML Registry
6. RegistryResponse
Content +
Metadata
4. Content
Invocation
Control
File
Service
5. commit
Management
Response
Persistent
Store
Content
Management
Service
Figure 53: Content Management Service: Inline Invocation Model
4727
9.3.2 De-coupled Invocation Model
4728
4729
4730
4731
4732
4733
4734
4735
4736
4737
4738
4739
4740
In a de-coupled invocation model a registry must invoke a Content Management Service
independent of or de-coupled from the Submit/UpdateObjectsRequest processing. Any errors
encountered during Content Management Service invocation must not have any impact on the
original Submit/UpdateObjectsRequest processing.
All metadata and content from the original Submit/UpdateObjectsRequest request must be
committed as an atomic transaction that is decoupled from the metadata and content that may be
generated by the Content Management Service invocation.
Figure 54 shows an abstract Content Management Service and how it is used by an ebXML
Registry using a de-coupled invocation model. The steps are as follows:
1. Same as in inline invocation model (Content Management Service is submitted).
2. Same as in inline invocation model (client submits content using
Submit/UpdateObjectsRequest).
Copyright © OASIS, 2002. All Rights Reserved
Page 131 of 188
OASIS/ebXML Registry Services Specification v3.0
4741
4742
4743
4744
4745
4746
4747
4748
4749
4750
4751
4752
4753
4754
4755
July 2017
3. The registry processes the Submit/UpdateObjectsRequest and commits it to persistent
store.
4. The registry returns a RegistryResponse to the client for the
Submit/UpdateObjectsRequest in step 2.
5. The registry determines there is a Content Management Service S1 configured for the
object type for the content submitted. It invokes S1 using a
ContentManagementServiceRequest and passes it the content.
6. The Content Management Service S1 processes the content and sends back a
ContentManagementServiceResponse.
7. If the ContentManagementServiceResponse includes any generated or modified content it
is committed to the persistent store as separate transaction. If there are any errors
encountered during de-coupled invocation of a Content Management Service then these
errors are logged by the registry in a registry specific manner and must not be reported
back to the client.
1. SubmitObjectRequest
Content +
Metadata
Service
2. SubmitObjectRequest
Registry Client
5. Content
Management
Service
Request
4756
4757
ebXML Registry
4. RegistryResponse
Content +
Metadata
6. Content
Invocation
Control
File
Service
3. commit
7. commit
Management
Response
Persistent
Store
Content
Management
Service
Figure 54: Content Management Service: De-coupled Invocation Model
4758
9.4 Content Management Service Protocol
4759
4760
4761
This section describe the abstract Content Management Service protocol that is the baseprotocol for other concrete protocols such as Validate Content protocol and Catalog Content
protocol. The concrete protocols will be defined later in this document.
4762
9.4.1 ContentManagementServiceRequestType
4763
4764
The ContentManagementServiceRequestType must be the abstract base type for all requests sent
from a registry to a Content Management Service.
Copyright © OASIS, 2002. All Rights Reserved
Page 132 of 188
OASIS/ebXML Registry Services Specification v3.0
4765
July 2017
Syntax:
4766
4767
Figure 55: ContentManagementServiceRequestType Syntax
4768
Parameters:
4769
4770
The following parameters are parameters that are either newly defined for this type or are
inherited and have additional semantics beyond those defined in the base type description.
4771
4772
4773
4774
4775
4776
InvocationControlFile: This parameter specifies the ExtrinsicObject for a
repository item that the caller wishes to specify as the Invocation Control File.
This specification does not specify the format of this file. There must be a
corresponding repository item as an attachment to this request. The corresponding
repository item should follow the same rules as attachments in
Submit/UpdateObjectsRequest.
4777
4778
4779
4780
4781
4782
OriginalContent: This parameter specifies the RegistryObjects that will be
processed by the content management service. In case of ExtrinsicObject
instances within the OriginalContent there may be repository items present as
attachments to the ContentManagementServiceRequest. This specification does
not specify the format of such repository items. The repository items should
follow the same rules as attachments in Submit/UpdateObjectsRequest.
4783
4784
Returns:
4785
This request returns a ContentManagementServiceResponse. See section 9.4.2 for details.
4786
Exceptions:
4787
4788
In addition to the exceptions returned by base request types, the following exceptions may be
returned:
4789
4790
MissingRepositoryItemException: signifies that the caller did not provide a
repository item as an attachment to this request when the Service requires it.
4791
4792
4793
InvocationControlFileException: signifies that the InvocationControlFile(s)
provided by the caller do not match the InvocationControlFile(s) expected by the
Service.
4794
4795
UnsupportedContentException: signifies that this Service does not support the
content provided by the caller.
4796
Copyright © OASIS, 2002. All Rights Reserved
Page 133 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
4797
9.4.2 ContentManagementServiceResponseType
4798
4799
4800
4801
4802
The ContentManagementServiceResponseType is sent by a Content Management Service as a
response to a ContentManagementServiceRequestType. The
ContentManagementServiceResponseType is the abstract base type for all responses sent to a
registry from a Content Management Service. It extends the RegistryResponseType and does not
define any new parameters.
4803
4804
Syntax:
4805
4806
4807
4808
Figure 56: Content ContentManagementServiceResponseType Syntax
Parameters:
No new parameters are defined other than those inherited from RegistryResponseType.
4809
4810
9.5 Publishing / Configuration of a Content Management Service
4811
4812
4813
4814
4815
4816
4817
4818
4819
4820
4821
4822
4823
4824
4825
4826
4827
4828
4829
4830
Any publisher may publish an arbitrary Content Management Service to an ebXML Registry.
The Content Management Service must be published using the standard LifeCycleManager
interface.
The publisher must use the standard Submit/UpdateObjectsRequest to publish:
o A Service instance for the Content Management Service. In Figure 57 this is exemplified
by the defaultXMLCatalogingService in the upper-left corner. The Service instance must
have an Association with a ClassificationNode in the canonical ObjectType
ClassificationScheme as defined by [ebRIM]. The Service must be the sourceObject
while a ClassificationNode must be the targetObject. This association binds the Service
to that specific ObjectType. The associationType for this Association instance must be
“ContentManagementServiceFor”. The Service must be classified by the canonical
ContentManagementService ClassificationScheme as defined by [ebRIM]. For example it
may be classified as a “ContentValidationService” or a “ContentCatalogingService”.
o The Service instance may be classified by a ClassificationNode under the canonical
InvocationModel ClassificationScheme as defined by [ebRIM], to determine whether it
uses the Inline Invocation model or the De-coupled Invocation model.
o The Service instance may be classified by a ClassificationNode under the canonical
ErrorHandlingModel ClassificationScheme as defined by [ebRIM], to determine whether
the Service should fail on first error or simply log the error as warning and continue. See
9.6.4 section for details.
Copyright © OASIS, 2002. All Rights Reserved
Page 134 of 188
OASIS/ebXML Registry Services Specification v3.0
4831
4832
4833
4834
4835
4836
4837
4838
4839
4840
4841
4842
4843
4844
4845
4846
4847
4848
July 2017
o A ServiceBinding instance contained within the Service instance that must provide the
accessURI to the Cataloging Service.
o An optional ExternalLink instance on the ServiceBinding that is resolvable to a web page
describing:
o The format of the supported content to be Cataloged
o The format of the supported Invocation Control File
Note that no SpecificationLink is required since this specification [ebRS] is implicit for
Content Cataloging Services.
o One or more Invocation Control File(s) that must be an ExtrinsicObject and a repository
item pair. The ExtrinsicObject for the Invocation Control File must have a required
Association with associationType of “InvocationControlFileFor”. This is exemplified by
the cppCatalogingServiceXSLT and the oagBODCatalogingServiceXSLT objects in
Figure 57 (left side of picture). The Invocation Control File must be the sourceObject
while a ClassificationNode in the canonical ObjectType ClassificationScheme must be
the targetObject.
Figure 57: Cataloging Service Configuration
Copyright © OASIS, 2002. All Rights Reserved
Page 135 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
4849
4850
4851
4852
4853
4854
4855
Figure 57 shows an example of the configuration of the default XML Cataloging Service
associated with the objectType for XML content. This Cataloging Service may be used with any
XML content that has its objectType attribute hold a reference to the xmlObjectType
ClassificationNode or one of its descendents.
The figure also shows two different Invocation Control Files, cppCatalogingServiceXSLT and
oagBODCatalogingServiceXSLT that may be used to catalog ebXML CPP and OAG Business
Object Documents (BOD) respectively.
4856
9.5.1 Multiple Content Management Services and Invocation Control Files
4857
4858
4859
4860
4861
4862
4863
4864
4865
4866
4867
4868
This specification allows clients to submit multiple Content Management Services of the same
type (e.g. validation, cataloging) and multiple Invocation Control Files for the same objectType.
Content Management Services of the same type of service for the same ObjectType are referred
to as peer Content Management Services.
4869
9.6 Invocation of a Content Management Service
4870
This section describes how a registry invokes a Content Management Service.
4871
9.6.1 Resolution Algorithm For Service and Invocation Control File
4872
4873
4874
When a registry receives a submission of a RegistryObject, it must use the following algorithm
to determine or resolve the Content Management Services and Invocation Control Files to be
used for dynamic content management for the RegistryObject:
When there are multiple Content Management Services and Invocation Control Files for the
same ObjectType there must be an unambiguous association between a Content Management
Service and its Invocation Control File(s). This must be defined by an Association instance with
Association type of “InvocationControlFileFor” where the ExtrinsicObject for each Invocation
Control File is the sourceObject and the Service is the targetObject.
The order of invocation of peer Content Management Services is undefined and may be
determined in a registry specific manner.
4875
4876
1. Get the objectType attribute of the RegistryObject.
4877
4878
4879
4880
4881
4882
2. Query to see if the ClassificationNode referenced by the objectType is the targetObject of
an Association with associationType of ContentManagementServiceFor. If desired
Association is not found for this ClassificationNode then repeat this step with its parent
ClassificationNode. Repeat until the desired Association is found or until the parent is the
ClassificationScheme. If desired Association(s) is found then repeat following steps for
each such Association instance.
4883
4884
4885
3. Check if the sourceObject of the desired Association is a Service instance. If not, log an
InvalidConfigurationException. If it is a Service instance, then use this Service as the
Content Management service for the RegistryObject.
Copyright © OASIS, 2002. All Rights Reserved
Page 136 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
4886
4887
4888
4889
4890
4. Query to see if the objectType ClassificationNode is the targetObject of one or more
Association with associationType of InvocationControlFileFor. If desired Association is
not found for this ClassificationNode then repeat this step with its parent
ClassificationNode. Repeat until the desired Association is found or until the parent is the
ClassificationScheme.
4891
4892
4893
4894
4895
4896
4897
4898
5. If desired Association(s) are found then check if the sourceObject of the desired
Association is an ExtrinsicObject instance. If not, log an InvalidConfigurationException.
If sourceObject is an ExtrinsicObject instance, then use its repository item as an
Invocation Control File. If there are multiple InvocationControlFiles then all of them
must be provided when invoking the Service.
The above algorithm allows for objectType hierarchy to be used to configure Content
Management Services and Invocation Control Files with varying degrees of specificity or
specialization with respect to the type of content.
4899
9.6.2 Audit Trail and Cataloged Content
4900
4901
4902
4903
4904
4905
The Cataloged Content generated as a result of the invocation of a Content Management Service
has an audit trail consistent with RegistryObject instances that are submitted by Registry Clients.
However, since a Registry Client does not submit Cataloged Content, the user attribute of the
AuditableEvent instances for such Cataloged Content references the Service object for the
Content Management Service that generated the Cataloged Content. This allows an efficient way
to distinguish Cataloged Content from content submitted by Registry Clients.
4906
9.6.3 Referential Integrity
4907
4908
A registry must maintain referential integrity between the RegistryObjects and repository items
invocation of a Content Management Service.
4909
9.6.4 Error Handling
4910
4911
4912
4913
4914
4915
4916
4917
4918
4919
4920
4921
If the Content Management Service is classified by the “FailOnError” ClassificationNode under
canonical ErrorHandlingModel ClassificationScheme as defined by [ebRIM], then the registry
must stop further processing of the Submit/UpdateObjectsRequest and return status of “Failure”
upon first error returned by a Content Management Service Invocation.
If the Content Management Service is classified by the “LogErrorAndContinue”
ClassificationNode under ErrorHandlingModel then the registry must continue to process the
Submit/UpdateObjectsRequest and not let any Content Management Service invocation error to
affect the storing of the RegistryObjects and repository items that were submitted. Such errors
should be logged as Warnings within the RegistryResponse returned to the client. In this case a
registry must return a normal response with status = “Success” if the submitted content and
metadata is stored successfully even when there are errors encountered during dynamic
invocation of one or more Content Management Service.
4922
9.7 Validate Content Protocol
4923
4924
4925
The interface of a Content Validation Service must implement a single method called
validateContent. The validateContent method accepts a ValidateContentRequest as parameter
and returns a ValidateContentResponse as its response if there are no errors.
Copyright © OASIS, 2002. All Rights Reserved
Page 137 of 188
OASIS/ebXML Registry Services Specification v3.0
4926
4927
4928
4929
4930
July 2017
The OriginalContent element within a ValidateContentRequest must contain exactly one
RegistryObject that needs to be cataloged. The resulting ValidateContentResponse contains the
status attribute that communicates whether the RegistryObject (and its content) are valid or not.
The Validate Content protocol does not specify the implementation details of any specific
Content Validation Service.
4931
4932
Figure 58: Validate Content Protocol
4933
9.7.1 ValidateContentRequest
4934
4935
4936
4937
The ValidateContentRequest is used to pass content to a Content Validation Service so that it can
validate the specified RegistryObject and any associated content. The RegistryObject typically is
an ExternalLink (in case of external content) or an ExtrinsicObject. The ValidateContentRequest
extends the base type ContentManagementServiceRequestType.
4938
Syntax:
4939
4940
Figure 59: ValidateContentRequest Syntax
4941
Parameters:
4942
4943
The following parameters are parameters that are either newly defined for this type or are
inherited and have additional semantics beyond those defined in the base type description.
4944
InvocationControlFile: Inherited from base type. This parameter may not be
Copyright © OASIS, 2002. All Rights Reserved
Page 138 of 188
OASIS/ebXML Registry Services Specification v3.0
4945
July 2017
present. If present its format is defined by the Content Validation Service.
4946
4947
4948
4949
4950
4951
OriginalContent: Inherited from base type. This parameter must contain exactly
one RegistryObject (e.g. ExternalLink, ExtrinsicObject) and potentially an
associated content. This specification does not specify the format of the content. If
it is an ExtrinsicObject then there may be a corresponding repository item as an
attachment to this request that is the content. The corresponding repository item
should follow the same rules as attachments in Submit/UpdateObjectsRequest.
4952
4953
Returns:
4954
This request returns a ValidateContentResponse. See section 9.7.2 for details.
4955
Exceptions:
4956
4957
In addition to the exceptions returned by base request types, the following exceptions may be
returned:
4958
4959
4960
InavlidContentException: signifies that the specified content was found to be
invalid. The exception should include enough detail for the client to be able to
determine how to make the content valid.
4961
4962
9.7.2 ValidateContentResponse
4963
4964
The ValidateContentResponse is sent by the Content Validation Service as a response to a
ValidateContentRequest.
4965
4966
Syntax:
4967
4968
Figure 60: ValidateContentResponse Syntax
4969
Parameters:
4970
4971
The following parameters are parameters that are either newly defined for this type or are
inherited and have additional semantics beyond those defined in the base type description.
4972
4973
4974
4975
4976
status: Inherited attribute. This enumerated value is used to indicate the status of
the request. Values for status are as follows:
Success - This status specifies that the content specified in the
ValidateContentRequest was valid.
Copyright © OASIS, 2002. All Rights Reserved
Page 139 of 188
OASIS/ebXML Registry Services Specification v3.0
4977
4978
4979
4980
4981
4982
July 2017
Failure - This status specifies that the request failed. If the error returned is an
InvalidContentException then the content specified in the
ValidateContentRequest was invalid. If there was some other failure
encountered during the processing of the request then a different error may be
returned.
4983
9.8 Catalog Content Protocol
4984
4985
4986
4987
4988
4989
4990
4991
4992
The interface of the Content Cataloging Service must implement a single method called
catalogContent. The catalogContent method accepts a CatalogContentRequest as parameter and
returns a CatalogContentResponse as its response if there are no errors.
The CatalogContentRequest may contain repository items that need to be cataloged. The
resulting CatalogContentResponse contains the metadata and possibly content that gets generated
or updated by the Content Cataloging Service as a result of cataloging the specified repository
items.
The Catalog Content protocol does not specify the implementation details of any specific
Content Cataloging Service.
4993
4994
Figure 61: Catalog Content Protocol
4995
9.8.1 CatalogContentRequest
4996
4997
4998
4999
The CatalogContentRequest is used to pass content to a Content Cataloging Service so that it can
create catalog metadata for the specified RegistryObject and any associated content. The
RegistryObject typically is an ExternalLink (in case of external content) or an ExtrinsicObject.
The CatalogContentRequest extends the base type ContentManagementServiceRequestType.
Copyright © OASIS, 2002. All Rights Reserved
Page 140 of 188
OASIS/ebXML Registry Services Specification v3.0
5000
July 2017
Syntax:
5001
5002
Figure 62: CatalogContentRequest Syntax
5003
Parameters:
5004
5005
The following parameters are parameters that are either newly defined for this type or are
inherited and have additional semantics beyond those defined in the base type description.
5006
5007
InvocationControlFile: Inherited from base type. If present its format is defined
by the Content Cataloging Service.
5008
5009
5010
5011
5012
5013
OriginalContent: Inherited from base type. This parameter must contain exactly
one RegistryObject (e.g. ExternalLink, ExtrinsicObject) and potentially an
associated content. This specification does not specify the format of the content. If
it is an ExtrinsicObject then there may be a corresponding repository item as an
attachment to this request that is the content. The corresponding repository item
should follow the same rules as attachments in Submit/UpdateObjectsRequest.
5014
5015
Returns:
5016
This request returns a CatalogContentResponse. See section 9.8.2 for details.
5017
Exceptions:
5018
5019
In addition to the exceptions returned by base request types, the following exceptions may be
returned:
5020
5021
CatalogingException: signifies that an exception was encountered in the
Cataloging algorithm for the service.
5022
5023
9.8.2 CatalogContentResponse
5024
5025
The CatalogContentResponse is sent by the Content Cataloging Service as a response to a
CatalogContentRequest.
5026
Copyright © OASIS, 2002. All Rights Reserved
Page 141 of 188
OASIS/ebXML Registry Services Specification v3.0
5027
July 2017
Syntax:
5028
5029
Figure 63: CatalogContentResponse Syntax
5030
Parameters:
5031
5032
The following parameters are parameters that are either newly defined for this type or are
inherited and have additional semantics beyond those defined in the base type description.
5033
5034
5035
5036
5037
5038
5039
CatalogedContent: This parameter specifies a collection of RegistryObject
instances that were created or updated as a result of dynamic content cataloging
by a content cataloging service. The Content Cataloging Service may add
metadata such as Classifications, ExternalIdentifiers, name, description etc. to the
CatalogedContent element. There may be an accompanying repository item as an
attachment to this response message if the original repository item was modified
by the request.
5040
5041
5042
9.9 Illustrative Example: Default XML Cataloging Service
5043
5044
5045
5046
5047
5048
5049
5050
5051
5052
5053
5054
Figure 64 shows a UML instance diagram to illustrate how a Content Cataloging Service is used.
This Content Cataloging Service is the normative Default XML Cataloging Service described in
section 9.10.
o In the center we see a Content Cataloging Service name defaultXMLCataloger Service.
o On the left we see a CPP repository item and its ExtrinsicObject inputExtObjForCPP
being input as Original Content to the defaultXMLCataloging Service.
o On top we see an XSLT style sheet repository item and its ExtrinsicObject that is
configured as an Invocation Control File for the defaultXMLCataloger Service.
o On the right we see the outputExtObjForCPP, which is the modified ExtrinsicObject for
the CPP. We also see a Classification roleClassification, which classifies the CPP by the
Role element within the CPP. These are the Cataloged Content generated as a result of
the Cataloging Service cataloging the CPP.
Copyright © OASIS, 2002. All Rights Reserved
Page 142 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
Invocation Control File
OriginalContent
5055
5056
CatalogedContent
Figure 64: Example of CPP cataloging using Default XML Cataloging Service
5057
5058
9.10 Default XML Content Cataloging Service
5059
5060
5061
5062
5063
5064
5065
5066
5067
5068
5069
5070
5071
5072
5073
5074
5075
5076
5077
5078
An ebXML Registry must provide the default XML Content Cataloging Service natively as a
built-in service with the following constraints:
There is exactly one Service instance for the Default XML Content Cataloging Service
The Service is an XSLT engine
The Service may be invoked with exactly one Invocation Control File
The Original Content for the Service must be XML document(s)
The Cataloged Content for the Service must be XML document(s)
The Invocation Control File must be an XSLT style sheet
Each invocation of the Service may be with different Invocation Control File (XSLT
style sheet) depending upon the objectType of the RegistryObject being cataloged. Each
objectType should have its own unique XSLT style sheet. For example, ebXML CPP
documents should have a specialized ebXML CPP Invocation Control XSLT style sheet.
There Service must have at least one input XML document that is a RegistryObject.
Typically this is an ExtrinsicObject or an ExternalLink.
The Service may have at most one additional input XML document that is the content
represented by the RegistryObject (e.g. a CPP document or an HL7 Conformance
Profile). The optional second input must be referenced within the XSLT Style sheet by a
using the “document” function with the document name specified by variable
“repositoryItem” as in “document($repositoryItem)”. A registry must define the variable
“repositoryItem” when invoking the default XML Cataloging Service.
Copyright © OASIS, 2002. All Rights Reserved
Page 143 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
5079
5080
5081
5082
5083
The default XML Content Cataloging Service must apply the XSLT style sheet to the
input XML instance document(s) in an XSLT transformation to generate the Cataloged
Output.
The Default XML Content Cataloging Service is a required normative feature of an ebXML
Registry.
5084
9.10.1 Publishing of Default XML Content Cataloging Service
5085
5086
5087
An ebXML Registry must provide the default XML Content Cataloging Service natively as a
built-in service. This built-in service must be published to the registry as part of the intrinsic
bootstrapping of required data within the registry.
Copyright © OASIS, 2002. All Rights Reserved
Page 144 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
5088
10 Event Notification Service
5089
5090
5091
5092
5093
5094
5095
5096
5097
5098
This chapter defines the Event Notification feature of the OASIS ebXML Registry. The Event
Notification feature is an optional but normative feature of the ebXML Registry.
Event Notification feature allows OASIS ebXML Registries to notify its users and / or other
registries about events of interest. It allows users to stay informed about registry events without
being forced to periodically poll the registry. It also allows a registry to propagate internal
changes to other registries whose content might be affected by those changes.
ebXML registries support content-based Notification where interested parties express their
interest in form of a query. This is different from subject–based (sometimes referred to as topicbased) notification, where information is categorized by subjects and interested parties express
their interests in those predefined subjects.
5099
10.1 Use Cases
5100
5101
The following use cases illustrate different ways in which ebXML registries notify users or other
registries.
5102
10.1.1 CPP Has Changed
5103
5104
5105
A user wishes to know when the CPP [ebCPP] of her partner is updated or superceded by
another CPP. When that happens she may wish to create a CPA [ebCPP] based upon the new
CPP.
5106
10.1.2 New Service is Offered
5107
5108
5109
A user wishes to know when a new Plumbing service is offered in her town and be notified every
10 days. When that happens, she might try to learn more about that service and compare it with
her current Plumbing service provider’s offering.
5110
10.1.3 Monitor Download of Content
5111
5112
5113
User wishes to know whenever her CPP [ebCPP] is downloaded in order to evaluate on an
ongoing basis the success of her recent advertising campaign. She might also want to analyze
who the interested parties are.
5114
10.1.4 Monitor Price Changes
5115
5116
5117
User wishes to know when the price of a product that she is interested in buying drops below a
certain amount. If she buys it she would also like to be notified when the product has been
shipped to her.
5118
10.1.5 Keep Replicas Consistent With Source Object
5119
5120
5121
5122
In order to improve performance and availability of accessing some registry objects, a local
registry may make replicas of certain objects that are hosted by another registry. The registry
would like to be notified when the source object for a replica is updated so that it can
synchronize the replica with the latest state of the source object.
Copyright © OASIS, 2002. All Rights Reserved
Page 145 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
5123
10.2 Registry Events
5124
5125
5126
5127
5128
Activities within a registry result in meaningful events. Typically, registry events are generated
when a registry processes client requests. In addition, certain registry events may be caused by
administrative actions performed by a registry operator. [ebRIM] defines the AuditableEvent
class, instances of which represent registry events. When such an event occurs, an
AuditableEvent instance is generated by the registry.
5129
10.3 Subscribing to Events
5130
5131
5132
5133
5134
5135
5136
5137
5138
5139
5140
5141
5142
5143
5144
5145
5146
5147
5148
5149
5150
5151
5152
5153
5154
5155
5156
5157
5158
5159
5160
5161
5162
5163
5164
5165
5166
5167
A User may create a subscription with a registry if she wishes to receive notification for a
specific type of event. A User creates a subscription by submitting a Subscription instance to a
registry using the SubmitObjectsRequest. If a Subscription is submitted to a registry that does
not support event notification then the registry must return an UnsupportedCapabilityException.
The listing below shows a sample Subscription that uses a pre-defined SQL query as its selector,
that will result in an email notification to the user whenever a Service is created that is classified
as a “Plumbing” service and located in “A Little Town”.
The SQL query within the selector in plain English says the following:
Find all Services that are Created AND classified by ClassificationNode
where ClassificationNode's Path ends with string "Plumbing", AND classified
by ClassificationNode where ClassificationNode's Code contains string "A
Little Town".
<?xml version="1.0" encoding="UTF-8"?>
<tns:Subscription xmlns:tns="urn:oasis:names:tc:ebxml-regrep:rim:xsd:3.0"
xmlns:query="urn:oasis:names:tc:ebxml-regrep:query:xsd:3.0"
xmlns:rim="urn:oasis:names:tc:ebxml-regrep:rim:xsd:3.0"
xmlns:rs="urn:oasis:names:tc:ebxml-regrep:rs:xsd:3.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:oasis:names:tc:ebxml-regrep:rim:xsd:3.0 ../../../ebxmlrrspec/misc/schema/v3/rim.xsd urn:oasis:names:tc:ebxml-regrep:query:xsd:3.0
../../../ebxmlrr-spec/misc/schema/v3/query.xsd " id="e3373a7b-4958-4e55-8820d03a191fb76a" notificationInterval="P10D" selector="urn:uuid:8ea2c0f5-b14a-4f4688b2-f69e35405d86">
<!-- The selector is a reference to a query object that has the following query defined
SELECT * FROM Service s, AuditableEvent e, AffectectedObject ao,
Classification c1, Classification c2
ClassificationNode cn1, ClassificationNode cn2 WHERE
e.eventType = 'Created' AND ao.id = s.id AND ao.parent=e.id AND
c1.classifiedObject = s.id AND c1.classificationNode = cn1.id AND
cn1.path LIKE '%Plumbing' AND
c2.classifiedObject = s.id AND c2.classificationNode = cn2.id AND
cn2.path LIKE '%A Little Town%'
-->
Copyright © OASIS, 2002. All Rights Reserved
Page 146 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
5168
5169
5170
5171
</Selector>
<Action xsi:type="tns:NotifyActionType" notificationOption="Objects"
endPoint="mailto:[email protected]"/>
</tns:Subscription>
5172
10.3.1 Event Selection
5173
5174
5175
5176
In order for a User to only be notified of specific events of interest, she must specify a reference
to a stored AdHocQuery via the selector attribute within the Subscription instance. The query
determines whether an event qualifies for that Subscription or not. The query syntax is the
standard ad hoc query syntax described in chapter 8.
5177
10.3.2 Notification Action
5178
5179
5180
5181
5182
5183
5184
5185
5186
5187
5188
5189
5190
When creating a Subscription, a User may also specify Actions within the subscription that
specify what the registry must do when an event matching the Subscription (subscription event)
transpires.
A user may omit specifying an Action within a Subscription if does not wish to be notified by the
registry. A user may periodically poll the registry and pull the pending Notifications.
[ebRIM] defines two standard ways that a NotifyAction may be used:
Email NotifyAction that allows delivery of event notifications via email to a human user
or to an email end point for a software component or agent.
Service NotifyAction that allows delivery of event notifications via a programmatic
interface by invocating a specified listener web service.
For each event that transpires in the registry, if the registry supports event notification, it must
check all registered and active Subscriptions and see if any Subscriptions match the event. If a
match is found then the registry performs the Notification Actions required for the Subscription.
5191
10.3.3 Subscription Authorization
5192
5193
5194
A registry may use registry specific policies to decide which User is authorized to create a
subscription and to what events. A Registry must return an AuthorizationException in the event
that an Unauthorized User submits a Subscription to a registry.
5195
10.3.4 Subscription Quotas
5196
5197
5198
5199
A registry may use registry specific policies to decide an upper limit on the number of
Subscriptions a User is allowed to create. A Registry must return a QuotaExceededException in
the event that an Authorized User submits more Subscriptions than allowed by their registry
specific quota.
5200
10.3.5 Subscription Expiration
5201
5202
5203
5204
5205
Each subscription defines a startDate and and endDate attribute which determines the period
within which a Subscription is active. Outside the bounds of the active period, a Subsription may
exist in an expired state within the registry. A registry may remove an expired Subscription at
any time. In such cases the identity of a RegistryOperator User must be used for the request in
order to have sufficient authorization to remove a User’s Subscription.
Copyright © OASIS, 2002. All Rights Reserved
Page 147 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
5206
5207
A Registry must not consider expired Subscriptions when delivering notifications for an event to
its Subscriptions. An expired Subscription may be renewed by submitting a new Subscription.
5208
10.3.6 Subscription Rejection
5209
5210
5211
5212
A Registry may reject a Subscription if it is too costly to support. For instance a Subscription that
wishes to be notified of any change in any object may be too costly for most registries. A
Registry MUST return a SubscriptionTooCostlyException in the event that an Authorized User
submits a Subscription that is too costly for the registry to process.
5213
10.4 Unsubscribing from Events
5214
5215
5216
5217
A User may terminate a Subscription with a registry if she no longer wishes to be notified of
events related to that Subscription. A User terminates a Subscription by deleting the
corresponding Subscription object using the RemoveObjectsRequest to the registry.
Removal of a Subscription object follows the same rules as removal of any other object.
5218
10.5 Notification of Events
5219
5220
5221
5222
5223
5224
5225
5226
5227
5228
5229
5230
5231
5232
5233
5234
5235
5236
5237
5238
5239
5240
5241
5242
5243
5244
5245
5246
5247
5248
5249
5250
5251
5252
5253
5254
A registry performs the Actions for a Subscription in order to actually deliver the events.
However, regardless of the specific delivery action, the registry must communicate the
Subscription events. The Subscription events are delivered within a Notification instance as
described by [ebRIM]. In case of Service NotifyAction, the Notification is delivered to a handler
service conformant to the RegistryClient interface described in section 6.7.3. In case of an Email
NotifyAction the notification is delivered an email address.
The listing below shows a sample Notification matching the subscription example in section
10.3:
<?xml version="1.0" encoding="UTF-8"?>
<tns:Notification
xmlns:tns="urn:oasis:names:tc:ebxml-regrep:event:xsd:3.0"
xmlns:query="urn:oasis:names:tc:ebxml-regrep:query:xsd:3.0"
xmlns:rim="urn:oasis:names:tc:ebxml-regrep:rim:xsd:3.0"
xmlns:rs="urn:oasis:names:tc:ebxml-regrep:registry:xsd:3.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
status="Success" subscription="e3373a7b-4958-4e55-8820-d03a191fb76a"
xsi:type="tns:ObjectsNotificationType">
<rim:LeafRegistryObjectList>
<rim:Service id="f3373a7b-4958-4e55-8820-d03a191fb76a">
<rim:Name>
<rim:LocalizedString value="A Little Town
Plumbing"/>
</rim:Name>
<rim:Classification id="a3373a7b-4958-4e55-8820d03a191fb76a" classifiedObject="f3373a7b-4958-4e55-8820-d03a191fb76a"/>
<rim:Classification id="b3373a7b-4958-4e55-8820d03a191fb76a" classifiedObject="f3373a7b-4958-4e55-8820-d03a191fb76a"/>
</rim:Service>
</rim:LeafRegistryObjectList>
</tns:Notification>
[ebRIM] defines an extensible description of Notifications, making it possible to allow for
registry or application specific Notifications. It defines several normative types of Notifications.
Copyright © OASIS, 2002. All Rights Reserved
Page 148 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
5255
5256
5257
A client may specify the type of Notification they wish to receive using the notificationOption
attribute of the Action within the Subscription. The registry may override this notificationOption
based upon registry specific operational policies.
5258
10.6 Retrieval of Events
5259
5260
5261
The registry provides asynchronous PUSH style delivery of Notifications via notify Actions as
described earlier. However, a client may also use a PULL style to retrieve any pending events for
their Subscriptions. Pulling of events is done using the Get Notifications protocol.
5262
10.6.1 GetNotificationsRequest
5263
5264
The GetNotificationsRequest is used by a client to retrieve any pending events for their
Subscriptions.
5265
Syntax:
5266
5267
Figure 65: GetNotificationsRequest Syntax
5268
Parameters:
5269
5270
subscription: This parameter specifies the id to a Subscription object which the
client wishes to get Notifications.
5271
5272
Returns:
5273
This request returns a NotificationType. See section 0 for details.
5274
Exceptions:
5275
In addition to the exceptions common to all requests, the following exceptions may be returned:
5276
5277
5278
ObjectNotFoundException: signifies that the specified Subscription was not found
in the registry.
5279
10.6.2 NotificationType
5280
5281
NotificationsType is the simplest form of notification. It is the base type for all types of
Notifications.
5282
Copyright © OASIS, 2002. All Rights Reserved
Page 149 of 188
OASIS/ebXML Registry Services Specification v3.0
5283
July 2017
Syntax:
5284
5285
Figure 66: NotificationType Syntax
5286
Parameters:
5287
5288
subscription: This parameter specifies the id to a Subscription object for which
this is a Notification.
5289
10.6.3 ObjectRefsNotification
5290
5291
ObjectRefsNotification is a concrete type of Notification that may be sent by the registry as a
response to GetNotificationsRequest. It extends NotificationType.
5292
5293
Syntax:
5294
5295
Figure 67: ObjectRefsNotification Syntax
5296
Parameters:
5297
5298
5299
5300
5301
ObjectRefList: This parameter specifies a Collection of ObjectRef instances
where each ObjectRef is to a RegistryObject that matches the Subscription for
which this is a Notification. The client must retrieve the actual RegistryObjects
separately using the ObjectRefs.
5302
10.6.4 ObjectsNotification
5303
5304
ObjectsNotification is a concrete type of Notification that may be sent by the registry as a
response to GetNotificationsRequest. It extends NotificationType.
Copyright © OASIS, 2002. All Rights Reserved
Page 150 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
5305
5306
Syntax:
5307
5308
Figure 68: ObjectsNotification Syntax
5309
Parameters:
5310
5311
5312
5313
LeafRegistryObjectList: This parameter specifies a Collection of RegistryObject
instances where each RegistryObject is one tha was matches the Subscription for
which this is a Notification.
5314
10.7 Purging of Events
5315
5316
5317
A registry may periodically purge AuditableEvents in order to manage its resources. It is up to
the registry when such purging occurs. It is up to the registry to determine when undelivered
events are purged.
Copyright © OASIS, 2002. All Rights Reserved
Page 151 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
5318
11 Cooperating Registries Support
5319
5320
This chapter describes the capabilities and protocols that enable multiple ebXML registries to
cooperate with each other to meet advanced use cases.
5321
11.1 Cooperating Registries Use Cases
5322
5323
The following is a list of use cases that illustrate different ways that ebXML registries cooperate
with each other.
5324
11.1.1 Inter-registry Object References
5325
5326
5327
5328
A Submitting Organization wishes to submit a RegistryObject to a registry such that the
submitted object references a RegistryObject in another registry.
An example might be where a RegistryObject in one registry is associated with a RegistryObject
in another registry.
5329
5330
Figure 69: Inter-registry Object References
5331
5332
11.1.2 Federated Queries
5333
5334
5335
5336
A client wishes to issue a single query against multiple registries and get back a single response
that contains results based on all the data contained in all the registries. From the client’s
perspective it is issuing its query against a single logical registry that has the union of all data
within all the physical registries.
5337
11.1.3 Local Caching of Data from Another Registry
5338
5339
5340
5341
5342
5343
5344
5345
A destination registry wishes to cache some or all the data of another source registry that is
willing to share its data. The shared dataset is copied from the source registry to the destination
registry and is visible to queries on the destination registry even when the source registry is not
available.
Local caching of data may be desirable in order to improve performance and availability of
accessing that object.
An example might be where a RegistryObject in one registry is associated with a RegistryObject
in another registry, and the first registry caches the second RegistryObject locally.
Copyright © OASIS, 2002. All Rights Reserved
Page 152 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
5346
11.1.4 Object Relocation
5347
5348
A Submitting Organization wishes to relocate its RegistryObjects and/or repository items from
the registry where it was submitted to another registry.
5349
11.2 Registry Federations
5350
5351
5352
5353
A registry federation is a group of registries that have voluntarily agreed to form a loosely
coupled union. Such a federation may be based on common business interests and specialties that
the registries may share. Registry federations appear as a single logical registry, to registry
clients.
5354
5355
Figure 70: Registry Federations
5356
5357
5358
5359
5360
5361
5362
5363
Registry federations are based on a peer-to-peer (P2P) model where all participating registries
are equal. Each participating registry is called a registry peer. There is no distinction between the
registry operator that created a federation and those registry operators that joined that Federation
later.
Any registry operator may form a registry federation at any time. When a federation is created it
must have exactly one registry peer which is the registry operated by the registry operator that
created the federation.
Any registry may choose to voluntarily join or leave a federation at any time.
5364
11.2.1 Federation Metadata
5365
5366
5367
5368
5369
5370
5371
The Registry Information model defines the Registry and Federation classes, instances of these
classes and the associations between these instances describe a federation and its members. Such
instance data is referred to as Federation Metadata. The Registry and Federation classes are
described in detail in [ebRIM].
The Federation information model is summarized here as follows:
o A Federation instance represents a registry federation.
o A Registry instance represents a registry that is a member of the Federation.
Copyright © OASIS, 2002. All Rights Reserved
Page 153 of 188
OASIS/ebXML Registry Services Specification v3.0
5372
5373
5374
5375
July 2017
o An Association instance with associationType of HasFederationMember represents
membership of the registry in the federation. This Association links the Registry instance
and the Federation instance.
5376
5377
Figure 71: Federation Metadata Example
5378
11.2.2 Local Vs. Federated Queries
5379
5380
5381
5382
A federation appears to registry clients as a single unified logical registry. An
AdhocQueryRequest sent by a client to a federation member may be local or federated. A new
boolean attribute named federated is added to AdhocQueryRequest to indicate whether the query
is federated or not.
5383
Local Queries
5384
5385
5386
5387
When the federated attribute of AdhocQueryRequest has the value of false then the query is a
local query. In the absence of a federated attribute the default value of federated attribute is false.
A local AdhocQueryRequest is only processed by the registry that receives the request. A local
AdhocQueryRequest does not operate on data that belongs to other registries.
5388
Federated Queries
5389
5390
5391
5392
5393
5394
5395
When the federated attribute of AdhocQueryRequest has the value of true then the query is a
federated query.
A federated query to any federation member must be routed by that member to all other
federation member registries as parallel-distributed queries. A federated query operates on data
that belongs to all members of the federation.
When a client submits a federated query to a registry that is not a member of a federation, the
registry must treat it as a local query.
Copyright © OASIS, 2002. All Rights Reserved
Page 154 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
5396
Membership in Multiple Federations
5397
5398
5399
5400
5401
5402
5403
A registry may be a member of multiple federations. In such cases if the federated attribute of
AdhocQueryRequest has the value of true then the registry must route the federated query to all
federations that it is a member of.
Alternatively, the client may specify the id of a specific federation that the registry is a member
of, as the value of the federation parameter. The type of the federation parameter is anyURI and
identifies the “id” attribute of the desired Federation.
In such cases the registry must route the federated query to the specified federation only.
5404
11.2.3 Federated Lifecycle Management Operations
5405
5406
5407
5408
5409
Details on how to create and delete federations and how to join and leave a federation are
described in 11.2.8.
All lifecycle operations must be performed on a RegistryObject within its home registry using
the operations defined by the LifeCycleManager interface. Unlike query requests, lifecycle
management requests do not support any federated capabilities.
5410
11.2.4 Federations and Local Caching of Remote Data
5411
5412
5413
5414
5415
5416
5417
5418
A federation member is not required to maintain a local cache of replicas of RegistryObjects and
repository items that belong to other members of the federation.
A registry may choose to locally cache some or all data from any other registry whether that
registry is a federation member or not. Data caching is orthogonal to registry federation and is
described in section 11.3.
Since by default there is minimal replication in the members of a federation, the federation
architecture scales well with respect to memory and disk utilization at each registry.
Data replication is often necessary for performance, scalability and fault-tolerance reasons.
5419
11.2.5 Caching of Federation Metadata
5420
5421
5422
5423
5424
5425
5426
5427
5428
5429
5430
A special case for local caching is the caching of the Federation and Registry instances and
related Associations that define a federation and its members. Such data is referred to as
federation metadata. A federation member is required to locally cache the federation metadata,
from the federation home for each federation that it is a member of. The reason for this
requirement is consistent with a Peer-to-Peer (P2P) model and ensures fault –tolerance in case
the Federation home registry is unavailable.
The federation member must keep the cached federation metadata synchronized with the master
copy in the Federation home, within the time period specified by the replicationSyncLatency
attribute of the Federation. Synchronization of cached Federation metadata may be done via
synchronous polling or asynchronous event notification using the event notification feature of the
registry.
5431
11.2.6 Time Synchronization Between Registry Peers
5432
5433
5434
Federation members are not required to synchronize their system clocks with each other.
However, each Federation member SHOULD keep its clock synchronized with an atomic clock
server within the latency described by the replicationSyncLatency attribute of the Federation.
Copyright © OASIS, 2002. All Rights Reserved
Page 155 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
5435
11.2.7 Federations and Security
5436
5437
Federation lifecycle management operations abide by the same security rules as standard
lifecycle management.
5438
11.2.8 Federation Lifecycle Management Protocols
5439
5440
5441
This section describes the various operations that manage the lifecycle of a federation and its
membership. A key design objective is to allow federation lifecycle operations to be done using
standard LifeCycleManager interface of the registry in a stylized manner.
5442
Joining a Federation
5443
5444
5445
5446
5447
5448
5449
5450
5451
5452
5453
The following rules govern how a registry joins a federation:
Each registry must have exactly one Registry instance within that registry for which it is
a home. The Registry instance is owned by the RegistryOperator and may be placed in
the registry using any operator specific means. The Registry instance must never change
its home registry.
A registry may request to join an existing federation by submitting an instance of an
Extramural Association that associates the Federation instance as sourceObject, to its
Registry instance as targetObject, using an associationType of HasFederationMember.
The home registry for the Association and the Federation objects must be the same.
The owner of the Federation instance must confirm the Extramural Association in order
for the registry to be accepted as a member of the federation.
5454
Creating a Federation
5455
5456
5457
5458
5459
5460
The following rules govern how a federation is created:
A Federation is created by submitting a Federation instance to a registry using
SubmitObjectsRequest.
The registry where the Federation is submitted is referred to as the federation home.
The federation home may or may not be a member of that Federation.
A federation home may contain multiple Federation instances.
5461
Leaving a Federation
5462
5463
5464
5465
The following rules govern how a registry leaves a federation:
A registry may leave a federation at any time by removing its HasFederationMember
Association instance that links it with the Federation instance. This is done using the standard
RemoveObjectsRequest.
5466
Dissolving a Federation
5467
5468
5469
5470
5471
The following rules govern how a federation is dissolved:
A federation is dissolved by sending a RemoveObjectsRequest to its home registry and
removing its Federation instance.
The removal of a Federation instance is controlled by the same Access Control Policies
that govern any RegistryObject.
Copyright © OASIS, 2002. All Rights Reserved
Page 156 of 188
OASIS/ebXML Registry Services Specification v3.0
5472
5473
5474
5475
5476
July 2017
The removal of a Federation instance is controlled by the same lifecycle management
rules that govern any RegistryObject. Typically, this means that a federation may not be
dissolved while it has federation members. It may however be deprecated at any time.
Once a Federation is deprecated no new members can join it.
5477
11.3 Object Replication
5478
5479
5480
5481
5482
5483
5484
5485
RegistryObjects within a registry may be replicated in another registry. A replicated copy of a
remote object is referred to as its replica. The remote object may be an original object or it may
be a replica. A replica from an original is referred to as a first-generation replica. A replica of a
replica is referred to as a second-generation replica (and so on).
The registry that replicates a remote object locally is referred to as the destination registry for the
replication. The registry that contains the remote object being replicated is referred to as the
source registry for the replication.
5486
5487
Figure 72: Object Replication
5488
5489
11.3.1 Use Cases for Object Replication
5490
5491
A registry may create a local replica of a remote object for a variety of reasons. A few sample
use cases follow:
5492
5493
5494
5495
5496
5497
5498
o Improve access time and fault tolerance via locally caching remote objects. For example,
a registry may automatically create a local replica when a remote ObjectRef is submitted
to the registry.
o Improve scalability by distributing access to hotly contested object, such as NAICS
scheme, across multiple replicas.
o Enable cooperating registry features such as hierarchical registry topology and local
caching of federation metadata.
Copyright © OASIS, 2002. All Rights Reserved
Page 157 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
5499
11.3.2 Queries And Replicas
5500
5501
5502
5503
5504
5505
A registry must support client queries to consider a local replica of remote object as if it were a
local object. Local replicas are considered within the extent of the data set of a registry as far as
local queries are concerned.
When a client submits a local query that retrieves a remote object by its id attribute, if the
registry contains a local replica of that object then the registry should return the state defined by
the local replica.
5506
11.3.3 Lifecycle Operations And Replicas
5507
5508
5509
LifeCycle operations on an original object must be performed at the home registry for that
object. LifeCycle operations on replicas of an original object only affect the replica and do not
have any impact on the original object.
5510
11.3.4 Object Replication and Federated Registries
5511
5512
5513
Object replication capability is orthogonal to the registry federation capability. Objects may be
replicated from any registry to any other registry without any requirement that the registries
belong to the same federation.
5514
11.3.5 Creating a Local Replica
5515
5516
5517
5518
5519
5520
5521
5522
5523
5524
5525
5526
5527
5528
Any Submitting Organization can create a replica by using the standard SubmitObjectsRequest.
If a registry receives a SubmitObjectRequest which has an RegistryObjectList containing a
remote ObjectRef, then it must create a replica for that remote ObjectRef.
In addition to Submitting Organizations, a registry itself may create a replica under specific
situations in a registry specific manner.
Creating a local replica requires the destination registry to read the state of the remote object
from the source registry and then create a local replica of the remote object.
A registry may use standard QueryManager interface to read the state of a remote object
(whether it is an original or a replica). No new APIs are needed to read the state of a remote
object. Since query functionality does not need prior registration, no prior registration or contract
is needed for a registry to read the state of a remote object.
Once the state of the remote object has been read, a registry may use registry specific means to
create a local replica of the remote object. Such registry specific means may include the use of
the LifeCycleManager interface.
5529
5530
A replica of a RegistryObject may be distinguished from an original since a replica must have its
home attribute point to the remote registry where the original for the replica resides.
5531
11.3.6 Transactional Replication
5532
5533
5534
5535
5536
Transactional replication enables a registry to replicate events in another registry in a
transactionally consistent manner. This is typically the case when entire registries are replicated
to another registry.
This specification defines a more loosely coupled replication model as an alternative to
transactional replication for the following reasons:
Copyright © OASIS, 2002. All Rights Reserved
Page 158 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
5537
5538
5539
5540
5541
5542
5543
5544
5545
Registry implementations are not required to implement transactional replication.
5546
11.3.7 Keeping Replicas Current
5547
5548
5549
5550
5551
A registry must keep its replicas current within the latency specified by the value of the
replicationSyncLatency attribute defined by the registry. This includes removal of the replica
when its original is removed from its home registry.
Replicas may be kept current using the event notification feature of the registry or via periodic
polling.
5552
11.3.8 Write Operations on Local Replica
5553
5554
5555
Local Replicas are read-only objects. Lifecycle management operations of RegistryObjects are
not permitted on local replicas. All lifecycle management operation to RegistryObjects must be
performed in the home registry for the object.
5556
11.3.9 Tracking Location of a Replica
5557
5558
5559
5560
5561
A local replica of a remote RegistryObject instance must have exactly one ObjectRef instance
within the local registry. The home attribute of the ObjectRef associated with the replica tracks
its home location. A RegistryObject must have exactly one home. The home for a RegistryObject
may change via Object Relocation as described in section 11.4. It is optional for a registry to
track location changes for replicas within it.
5562
11.3.10
5563
5564
5565
It is possible to have a remote ObjectRef to a RegistryObject that is a replica of another
RegistryObject. In such cases the home attribute of the ObjectRef contains the base URI to the
home registry for the replica.
5566
11.3.11
5567
5568
5569
A Submitting Organization can remove a replica by using the RemoveObjectsRequest. If a
registry receives a RemoveObjectsRequest that has an ObjectRefList containing a remote
ObjectRef, then it must remove the local replica for that remote ObjectRef.
5570
11.4 Object Relocation Protocol
5571
5572
5573
Every RegistryObject has a home registry and a User within the home registry that is the
publisher or owner of that object. Initially, the home registry is the where the object is originally
submitted. Initially, the owner is the User that submitted the object.
Transactional replication requires a tight coupling between registries participating in the
replication
Transactional replication is not a typical use case for registries
Loosely coupled replication as defined by this specification typically suffices for most
use cases
Transaction replication is very complex and error prone
Remote Object References to a Replica
Removing a Local Replica
Copyright © OASIS, 2002. All Rights Reserved
Page 159 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
5574
5575
5576
5577
A RegistryObject may be relocated from one home registry to another home registry using the
Object Relocation protocol.
Within the Object Relocation protocol, the new home registry is referred to as the destination
registry while the previous home registry is called the source registry.
5578
5579
5580
5581
5582
5583
5584
5585
5586
5587
5588
Figure 73: Object Relocation
The User at the source registry who owns the objects being relocated is referred to as the
ownerAtSource. The User at the destination registry, who is the new owner of the objects, is
referred to as the ownerAtDestination. While the ownerAtSource and the ownerAtDestination
may often be the same identity, the Object Relocation protocol treats them as two distinct
identities.
A special case usage of the Object Relocation protocol is to transfer ownership of
RegistryObjects from one User to another within the same registry. In such cases the protocol is
the same except for the fact that the source and destination registries are the same.
Following are some notable points regarding object relocation:
5589
5590
Object relocation does not require that the source and destination registries be in the same
federation or that either registry have a prior contract with the other.
5591
5592
5593
5594
5595
5596
5597
5598
5599
5600
5601
Object relocation must preserve object id. While the home registry for a RegistryObject
may change due to object relocation, its id never changes.
ObjectRelocation must preserve referential integrity of RegistryObjects. Relocated
objects that have references to an object that did not get relocated must preserve their
reference. Similarly objects that have references to a relocated object must also preserve
their reference. Thus, relocating an object may result in making the value of a reference
attribute go from being a local reference to being a remote reference or vice versa.
AcceptObjectsRequest does not include ObjectRefList. It only includes an opaque
transactonId identifying the relocateObjects transaction.
The requests defined by the Relocate Objects protocol must be sent to the source or
destination registry only.
Copyright © OASIS, 2002. All Rights Reserved
Page 160 of 188
OASIS/ebXML Registry Services Specification v3.0
5602
5603
5604
5605
5606
5607
5608
5609
5610
5611
July 2017
When an object is relocated an AuditableEvent of type “Relocated” must be recorded by
the sourceRegistry. Relocated events must have the source and destination registry’s base
URIs recorded as two Slots on the Relocated event. The names of these Slots are
sourceRegistry and destinationRegistry respectively.
Figure 74: Relocate Objects Protocol
Figure 74 illustrates the Relocate Objects Protocol. The participants in the protocol are the
ownerAtSource and ownerAtDestination User instances as well as the LifeCycleManager
interfaces of the sourceRegistry and destinationRegistry.
The steps in the protocol are described next:
5612
5613
5614
5615
5616
5617
1. The protocol is initiated by the ownerAtSource sending a RelocateObjectsRequest
message to the LifeCycleManager interface of the sourceRegistry. The sourceRegistry
must make sure that the ownerAtSource is authorized to perform this request. The id of
this RelocateObjectsRequest is used as the transaction identifier for this instance of the
protocol. This RelocateObjectsRequest message must contain an ad hoc query that
specifies the objects that are to be relocated.
5618
5619
5620
5621
5622
2. Next, the sourceRegistry must relay the same RelocateObjectsRequest message to the
LifeCycleManager interface of the destinationRegistry. This message enlists the
detsinationRegistry to participate in relocation protocol. The destinationRegistry must
store the request information until the protocol is completed or until a registry specific
period after which the protocol times out.
5623
5624
5625
5626
5627
3. The destinationRegistry must relay the RelocateObjectsRequest message to the
ownerAtSource. This notification may be done using the event notification feature of the
registry as described in chapter 10. The notification may be done by invoking a listener
Service for the ownerAtDestination or by sending an email to the ownerAtDestination.
This concludes the first phase of the Object Relocation protocol.
5628
5629
5630
5631
4. The ownerAtDestination at a later time may send an AcceptObjectsRequest message to
the destinationRegistry. This request must identify the object relocation transaction via
the correlationId. The value of this attribute must be the id of the original
RelocateObjectsRequest.
Copyright © OASIS, 2002. All Rights Reserved
Page 161 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
5632
5633
5634
5635
5636
5. The destinationRegistry sends an AdhocQueryRequest message to the sourceRegistry.
The source registry returns the objects being relocated as an AdhocQueryResponse. In
the event of a large number of objects this may involve multiple
AdhocQueryRequest/responses as described by the iterative query feature described in
section 8.1.4.
5637
5638
5639
5640
6. The destinationRegistry submits the relocated data to itself assigning the identity of the
ownerAtDestination as the owner. The relocated data may be submitted to the destination
registry using any registry specific means or a SubmitObjectsRequest. However, the
effect must be the same as if a SubmitObjectsRequest was used.
5641
5642
5643
7. The destinationRegistry notifies the sourceRegistry that the relocated objects have been
safely committed using the Event Notification feature of the registry as described in
chapter 10.
5644
5645
5646
8. The sourceRegistry removes the relocated objects using any registry specific means and
logging an AuditableEvent of type Relocated. This concludes the Object Relocation
transaction.
5647
11.4.1 RelocateObjectsRequest
5648
5649
Figure 75: RelocateObjectsRequest XML Schema
5650
Parameters:
5651
5652
5653
5654
5655
5656
5657
5658
5659
5660
5661
id: the attribute id provides the transaction identifier for this instance of the
protocol.
AdhocQuery: This element specifies an ad hoc query that selects the
RegistryObjects that are being relocated.
SourceRegistry: This element specifies the ObjectRef to the sourceRegistry
Registry instance. The value of this attribute must be a local reference when the
message is sent by the ownerAtSource to the sourceRegistry.
destinationRegistry: This element specifies the ObjectRef to the
destinationRegistry Registry instance.
ownerAtSource: This element specifies the ObjectRef to the ownerAtSource User
instance.
Copyright © OASIS, 2002. All Rights Reserved
Page 162 of 188
OASIS/ebXML Registry Services Specification v3.0
5662
5663
5664
July 2017
ownerAtDestination: This element specifies the ObjectRef to the
ownerAtDestination User instance.
5665
Returns:
5666
This request returns a RegistryResponse. See section 6.9.3 for details.
5667
Exceptions:
5668
In addition to the exceptions common to all requests, the following exceptions may be returned:
5669
5670
5671
5672
ObjectNotFoundException: signifies that the specified Registry or User was not
found in the registry.
11.4.2 AcceptObjectsRequest
5673
5674
Figure 76: AcceptObjectsRequest Syntax
5675
Parameters:
5676
5677
correlationId: Provides the transaction identifier for this instance of the protocol.
5678
Returns:
5679
This request returns a RegistryResponse. See section 6.9.3 for details.
5680
Exceptions:
5681
In addition to the exceptions common to all requests, the following exceptions may be returned:
5682
5683
5684
InvalidRequestException: signifies that the specified correlationId was not found
to match an ongoing RelocateObjectsRequest in the registry.
5685
11.4.3 Object Relocation and Remote ObjectRefs
5686
The following scenario describes what typically happens when a person moves:
5687
5688
5689
5690
5691
5692
5693
1. When a person moves from one house to another, other persons may have their old postal
addresses.
2. When a person moves, they leave their new address as the forwarding address with the
post office.
3. The post office forwards their mail for some time to their new address.
4. Eventually the forwarding request expires and the post office no longer forwards mail for
that person.
Copyright © OASIS, 2002. All Rights Reserved
Page 163 of 188
OASIS/ebXML Registry Services Specification v3.0
5694
5695
5696
5697
5698
5699
5700
5701
5702
5703
5704
5705
5706
5707
5708
5709
5710
5711
5712
5713
5714
July 2017
5. During this forwarding interval the person notifies interested parties of their change of
address.
The registry must support a similar model for relocation of RegistryObjects. The following steps
describe the expected behavior when an object is relocated.
1. When a RegistryObject O1 is relocated from one registry R1 to another registry R2, other
RegistryObjects may have remote ObjectRefs to O1.
2. The registry R1 must leave an AuditableEvent of type Relocated that includes the home
URI for the new registry R2.
3. As long as the AuditableEvent exists in R1, if R1 gets a request to retrieve O1 by id, it
must forward the request to R2 and transparently retrieve O1 from R2 and deliver it to the
client. The object O1 must include the home URI to R2 within the optional home
attribute of RegistryObject. Clients are advised to check the home attribute and update
the home attribute of their local ObjectRef to match the new home URI value for the
object.
4. Eventually the AuditableEvent is cleaned up after a registry specific interval. R1 is no
longer required to relay requests for O1 to R2 transparent to the client. Instead R1 must
return an ObjectNotFoundException.
5. Clients that are interested in the relocation of O1 and being notified of its new address
may choose to be notified by having a prior subscription using the event notification
facility of the registry. For example a Registry that has a remote ObjectRefs to O1 may
create a subscription on relocation events for O1. This however, is not required behavior.
5715
11.4.4 Notification of Object Relocation To ownerAtDestination
5716
5717
5718
5719
5720
5721
5722
5723
5724
This section describes how the destinationRegistry uses the event notification feature of the
registry to notify the ownerAtDestination of a Relocated event.
The destinationRegistry must send a Notification with the following required characteristics:
The notification must be an instance of a Notification element.
The Notification instance must have at least one Slot.
The Slot must have the name eventNotification.correlationId
The Slot must have the correlationId for the Object Relocation transaction as the value of
the Slot.
5725
11.4.5 Notification of Object Commit To sourceRegistry
5726
5727
5728
5729
5730
5731
5732
5733
This section describes how the destinationRegistry uses the event notification feature of the
registry to notify the sourceRegistry that it has completed committing the relocated objects.
The destinationRegistry must send a Notification with the following required characteristics:
The notification must be an instance of a Notification element.
The Notification instance must have at least one Slot.
The Slot must have the name eventNotification.objectsCommitted
The Slot must have the value of true.
Copyright © OASIS, 2002. All Rights Reserved
Page 164 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
5734
11.4.6 Object Relocation and Timeouts
5735
5736
5737
No timeouts are specified for the Object Relocation protocol. Registry implementations may
cleanup incomplete Object Relocation transactions in a registry specific manner as an
administrative task using registry specific policies.
Copyright © OASIS, 2002. All Rights Reserved
Page 165 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
5738
12 Registry Security
5739
5740
5741
This chapter describes the security features of the ebXML Registry. It is assumed that the reader
is familiar with the security related classes in the Registry information model as described in
[ebRIM]. Security glossary terms can be referenced from RFC 2828.
5742
12.1 Security Concerns
5743
5744
5745
5746
5747
5748
In the current version of this specification, we address data integrity and source integrity (item 1
in Appendix E.1). We have used a minimalist approach to address the access control concern as
in item 2 of Appendix E.1. By default, any Registered User identified by a User instance as
defined by [ebRIM] can publish content and anyone can view published content. In addition to
this default behaviour, the Registry Information Model [ebRIM] is designed to support more
sophisticated security policies in future versions of this specification.
5749
12.2 Integrity of Registry Content
5750
5751
5752
5753
5754
5755
It is assumed that most registries do not have the resources to validate the veracity of the content
submitted to them. The mechanisms described in this section can be used to ensure that any
tampering with the content can be detected. Furthermore, these mechanisms support
unambiguous identification of a Registered User as the submitter for any registry content. The
Registered User has to sign the contents before submission – otherwise the content will be
rejected.
5756
12.2.1 Message Payload Signature
5757
5758
5759
5760
5761
5762
5763
5764
5765
5766
5767
5768
5769
5770
The integrity of the Registry content requires that all submitted content be signed by the
Registered User that submits the content. The signature on the submitted content ensures that:
Any tampering of the content can be detected.
The content’s veracity can be ascertained by its association with a specific Registered User
and its indirect association with the Organization that the Registered User may be affiliated
with.
This section specifies the requirements for generation, packaging and validation of payload
signatures. A payload signature is packaged with the payload. Therefore the requirements apply
regardless of whether the Registry Client and the Registration Authority communicate over
standard SOAP with Attachments or ebXML Messaging Service [ebMS]. Currently, ebXML
Messaging Service does not specify the generation, validation and packaging of payload
signatures. The specification of payload signatures is left up to the application and therefore
defined by this specification for ebXML Registry client applications. The requirements on the
payload signatures augment the [ebMS] specification.
5771
Use Case
5772
5773
5774
5775
This Use Case illustrates the use of header and payload signatures (we discuss header signatures
later).
RC1 (Registry Client 1) signs the content (generating a payload signature) and publishes the
content along with the payload signature to the Registry.
Copyright © OASIS, 2002. All Rights Reserved
Page 166 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
5776
5777
5778
5779
5780
5781
5782
5783
5784
5785
5786
5787
12.2.2 Payload Signature Requirements
5788
Payload Signature Packaging Requirements
5789
5790
5791
5792
5793
5794
5795
5796
A payload signature is represented by a ds:Signature element. The payload signature must be
packaged with the payload as specified here. This packaging assumes that the payload is always
signed.
The payload and its signature must be enclosed in a MIME multipart message with a
Content-Type of multipart/related.
The first body part must contain the XML signature as specified in Section 0, “Payload
Signature Generation Requirements”.
The second body part must be the content.
5797
5798
The packaging of the payload signature with two payloads is as shown in the example in Section
8.4.4.
5799
Payload Signature Generation Requirements
5800
5801
5802
5803
5804
5805
5806
5807
5808
5809
5810
5811
5812
5813
5814
5815
5816
The ds:Signature element [XMLDSIG] for a payload signature must be generated as specified in
this section. Note: the “ds” name space reference is to http://www.w3.org/2000/09/xmldsig#
ds:SignatureMethod must be present. [XMLDSIG] requires that the algorithm be identified
using the Algorithm attribute. [XMLDSIG] allows more than one Algorithm attribute, and a
client may use any of these attributes. However, signing using the following Algorithm
attribute: http://www.w3.org/2000/09/xmldsig#dsa-sha1 will allow interoperability with all
XMLDSIG compliant implementations, since XMLDSIG requires the implementation of this
algorithm.
The ds:SignedInfo element must contain a ds:CanonicalizationMethod element. The following
Canonicalization algorithm (specified in [XMLDSIG]) must be supported
RC2 (Registry Client 2) retrieves RC1’s content from the Registry.
RC2 wants to verify that RC1 published the content. In order to do this, when RC2 retrieves
the content, the response from the Registration Authority to RC2 contains the following:
o Payload containing the content that has been published by RC1.
o RC1’s payload signature (represented by a ds:Signature element) over RC1’s published
content.
o The public key for validating RC1’s payload signature in ds:Signature element ( using the
KeyInfo element as specified in [XMLDSIG] ) so RC2 can obtain the public key for
signature (e.g. retrieve a certificate containing the public key for RC1).
o A ds:Signature element containing the header signature. Note that the Registration
Authority (not RC1) generates this signature.
http://www.w3.org/TR/2001/REC-xml-c14n-20010315
One ds:Reference element to reference each of the payloads that needs to be signed must be
created. The ds:Reference element:
o Must identify the payload to be signed using the URI attribute of the ds:Reference
element.
o Must contain the <ds:DigestMethod> as specified in [XMLDSIG]. A client must support
the following digest algorithm:
Copyright © OASIS, 2002. All Rights Reserved
Page 167 of 188
OASIS/ebXML Registry Services Specification v3.0
5817
5818
July 2017
http://www.w3.org/2000/09/xmldsig#sha1
o Must contain a <ds:DigestValue> which is computed as specified in [XMLDSIG].
5819
The ds:SignatureValue must be generated as specified in [XMLDSIG].
5820
5821
The ds:KeyInfo element may be present. However, when present, the ds:KeyInfo field is subject
to the requirements stated in Section 12.4, “KeyDistrbution and KeyInfo element”.
5822
Message Payload Signature Validation
5823
The ds:Signature element must be validated by the Registry as specified in the [XMLDSIG].
5824
Payload Signature Example
5825
5826
5827
5828
5829
5830
5831
5832
5833
5834
5835
5836
5837
5838
5839
5840
The following example shows the format of the payload signature:
5841
12.3 Authentication
5842
5843
The Registry must be able to authenticate the identity of the User associated with client requests
and also the owner of each repository item.
5844
5845
5846
5847
5848
5849
5850
The User can be identified by verifying the message header signature with the certificate of the
User. The certificate may be in the message itself or provided to the registry through means
unspecified in this specification. If not provided in the message, this specification does not
specify how the Registry correlates a specific message with a certificate. Each payload must also
be signed to ensure the integrity of that payload and to determine its owner. Authentication is
also required in order to identify the actions a User is authorized to perform with respect to
specific RegistryObject rosources in the Registry.
5851
5852
5853
5854
The Registry must perform authentication on a per message basis. From a security point of view,
all messages are independent and there is no concept of a session encompassing multiple
messages or conversations. Session support may be added as an optimization feature in future
versions of this specification.
5855
5856
5857
It is important to note that the message header signature can only guarantee data integrity. It does
not guarantee safety from “replay” attacks. True support for authentication requires timestamps
or nonce (nonrecurring series of numbers to identify each message) that are signed.
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<SignatureMethod Algorithm=”http://www.w3.org/TR/2000/09/xmldsig#dsa-sha1”/>
<ds:CanonicalizationMethod>
Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315">
</ds:CanonicalizationMethod>
<ds:Reference URI=#Payload1>
<ds:DigestMethod DigestAlgorithm="http://www.w3.org/TR/2000/09/xmldsig#sha1">
<ds:DigestValue> ... </ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
...
</ds:SignatureValue>
</ds:Signature>
Copyright © OASIS, 2002. All Rights Reserved
Page 168 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
5858
12.3.1 Message Header Signature
5859
5860
Message headers are signed to provide data integrity while the message is in transit. Note that the
signature within the message header also signs the digests of the payloads.
5861
Header Signature Requirements
5862
5863
5864
5865
5866
Message headers may be signed and are referred to as a header signature. When a Registered
User sends a request, the Registration Authority may use a pre-established contract or a default
policy to determine whether the response should contain a header signature. When a Registry
Guest sends a request, the Registration Authority may use a default policy to determine whether
the response contains a header signature.
5867
5868
5869
5870
5871
5872
5873
5874
This section specifies the requirements for generation, packaging and validation of a header
signature. These requirements apply when the Registry Client and Registration Authority
communicate using standard SOAP with Attachments. When ebXML MS is used for
communication, then the message handler (i.e. [ebMS]) specifies the generation, packaging and
validation of XML signatures in the SOAP header. Therefore the header signature requirements
do not apply when the ebXML MS is used for communication. However, payload signature
generation requirements (0) do apply whether standard SOAP with Attachments or ebXML MS
is used for communication.
5875
Packaging Requirements
5876
5877
5878
A header signature is represented by a ds:Signature element. The ds:Signature element generated
must be packaged in a <SOAP-ENV:Header> element. The packaging of the ds:Signature
element in the SOAP header field is shown in Section 8.4.4.
5879
Header Signature Generation Requirements
5880
5881
5882
5883
5884
The ds:Signature element [XMLDSIG] for a header signature must be generated as specified in
this section. A ds:Signature element contains:
ds:SignedInfo
ds:SignatureValue
ds:KeyInfo
5885
The ds:SignedInfo element must be generated as follows:
5886
5887
5888
5889
5890
1. ds:SignatureMethod must be present. [XMLDSIG] requires that the algorithm be identified
using the Algorithm attribute. While [XMLDSIG] allows more than one Algorithm Attribute,
a client must be capable of signing using only the following Algorithm attribute:
http://www.w3.org/2000/09/xmldsig#dsa-sha1. All XMLDSIG implementations conforming to the
[XMLDSIG] specification support this algorithm.
5891
5892
5893
2. The ds:SignedInfo element must contain a ds:CanonicalizationMethod element. The
following Canonicalization algorithm (specified in [XMLDSIG]) must be supported:
5894
5895
5896
5897
3. A ds:Reference element to include the <SOAP-ENV:Envelope> in the signature calculation.
This signs the entire ds:Reference element and:
o Must include the ds:Transform
http://www.w3.org/TR/2001/REC-xml-c14n-20010315
http://www.w3.org/2000/09/xmldsig#enveloped-signature
Copyright © OASIS, 2002. All Rights Reserved
Page 169 of 188
OASIS/ebXML Registry Services Specification v3.0
5898
5899
5900
5901
5902
5903
5904
5905
July 2017
This ensures that the signature (which is embedded in the <SOAP-ENV:Header>
element) is not included in the signature calculation.
o Must identify the <SOAP-ENV:Envelope> element using the URI attribute of the
ds:Reference element. The URI attribute is optional in the [XMLDSIG] specification.
The URI attribute must be an empty string (“”).
o Must contain the <ds:DigestMethod> as specified in [XMLDSIG]. A client must support
the digest algorithm: http://www.w3.org/2000/09/xmldsig#sha1
o Must contain a <ds:DigestValue>, which is computed as specified in [XMLDSIG].
5906
The ds:SignatureValue must be generated as specified in [XMLDSIG].
5907
5908
The ds:KeyInfo element may be present. When present, it is subject to the requirements stated in
Section 12.4, “KeyDistrbution and KeyInfo element”.
5909
Header Signature Validation Requirements
5910
5911
The ds:Signature element for the ebXML message header must be validated by the recipient as
specified by [XMLDSIG].
5912
Header Signature Example
5913
5914
5915
5916
5917
5918
5919
5920
5921
5922
5923
5924
5925
5926
5927
5928
5929
5930
5931
The following example shows the format of a header signature:
5932
12.4 Key Distribution and KeyInfo Element
5933
5934
5935
5936
5937
To validate a signature, the recipient of the signature needs the public key corresponding to the
signer’s private key. The participants may use the KeyInfo field of ds:Signature, or distribute the
public keys in an implementation specific manner. In this section we consider the case when the
public key is sent in the KeyInfo field. The following use cases need to be addressed:
Registration Authority needs the public key of the Registry Client to validate the signature
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<SignatureMethod Algorithm=http://www.w3.org/TR/2000/09/xmldsig#dsa-sha1/>
<ds:CanonicalizationMethod>
Algorithm="http://www.w3.org/TR/2000/CR-xml-c14n-2001026">
</ds:CanonicalizationMethod>
<ds:Reference URI= “”>
<ds:Transform>
http://www.w3.org/2000/09/xmldsig#enveloped-signature
</ds:Transform>
<ds:DigestMethod DigestAlgorithm="./xmldsig#sha1">
<ds:DigestValue> ... </ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
...
</ds:SignatureValue>
</ds:Signature>
Copyright © OASIS, 2002. All Rights Reserved
Page 170 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
5938
5939
5940
5941
5942
5943
5944
5945
5946
The following assumptions are also made:
5947
1. A Certificate is associated both with the Registration Authority and a Registry Client.
5948
5949
2. A Registry Client registers its certificate with the Registration Authority. The mechanism
used for this is not specified here.
5950
5951
3. A Registry Client obtains the Registration Authority’s certificate and stores it in its own local
key store. The mechanism is not specified here.
5952
Appendix F.8 contains a few scenarios on the use of KeyInfo field.
5953
12.5 Confidentiality
5954
12.5.1 On-the-wire Message Confidentiality
5955
5956
5957
It is suggested but not required that message payloads exchanged between Registry Clients and
the Registry be encrypted during transmission. This specification does not specify how payload
encryption is to be done.
5958
12.5.2 Confidentiality of Registry Content
5959
5960
5961
5962
In the current version of this specification, there are no provisions for confidentiality of Registry
content. All content submitted to the Registry may be discovered and read by any client. This
implies that the Registry and the client need to have an a priori agreement regarding encryption
algorithm, key exchange agreements, etc.
5963
12.6 Access Control and Authorization
5964
5965
5966
5967
The Registry must provide an access control and authorization mechanism based on the Access
Control Information Model defined in [ebRIM]. This model defines a default access control
policy that must be supported by the registry. In addition it also defines a binding to [XACML]
that allows fine-grained access control policies to be defined.
5968
12.6.1 Actors / Role Mapping
5969
5970
The following table shows the mapping of actors listed in Section 5.3 and their default roles.
Registry Client needs the public key of the Registration Authority to validate the Registry’s
signature.
Registry Client RC1 needs the public key of Registry Client RC2 to validate the content
signed by RC1.
[XMLDSIG] provides an optional ds:KeyInfo element that can be used to pass information
to the recipient for retrieving the public key. This field together with the procedures outlined
in this section is used to securely pass the public key to a recipient. If the KeyInfo field is
present, it must contain a X509 Certificate as specified in [XMLDSIG].
Copyright © OASIS, 2002. All Rights Reserved
Page 171 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
Actor
Role
Registered User
ContentOwner
Registry Administrator
RegistryAdministrator
Registration Authority
5971
Registry Guest
RegistryGuest
Registry Reader
RegistryGuest
Table 9: Default Actor to Role Mappings
5972
5973
Copyright © OASIS, 2002. All Rights Reserved
Page 172 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
5974
Appendix A
Web Service Architecture
5975
A.1 Registry Service Abstract Specification
5976
5977
5978
The normative definition of the Abstract Registry Service in WSDL is defined at the following
location on the web:
5979
A.2 Registry Service SOAP Binding
5980
5981
5982
5983
The normative definition of the concrete Registry Service binding to SOAP in WSDL is defined
at the following location on the web:
http://www.oasis-open.org/committees/regrep/documents/3.0/services/Registry.wsdl
http://www.oasis-open.org/committees/regrep/documents/3.0/services/RegistrySOAPBinding.wsdl
Copyright © OASIS, 2002. All Rights Reserved
Page 173 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
5984
Appendix B
ebXML Registry Schema Definitions
5985
B.1 RIM Schema
5986
5987
5988
The normative XML Schema definition that maps [ebRIM] classes to XML can be found at the
following location on the web:
5989
B.2 Registry Services Interface Base Schema
5990
5991
5992
5993
The normative XML Schema definition that defines the XML requests and responses supported
by the registry service interfaces in this document can be found at the following location on the
web:
5994
B.3 QueryManager Service Schema
5995
5996
5997
The normative XML Schema definition for the XML syntax for the QueryManager service
interface can be found at the following location on the web:
5998
B.4 LifecycleManager Service Schema
5999
6000
6001
The normative XML Schema definition for the XML syntax for the LifecycleManager service
interface can be found at the following location on the web:
6002
B.5 Examples of Instance Documents
6003
6004
6005
6006
A growing number of non-normative XML instance documents that conform to the normative
Schema definitions described earlier may be found at the following location on the web:
http://www.oasis-open.org/committees/regrep/documents/3.0/schema/rim.xsd
http://www.oasis-open.org/committees/regrep/documents/3.0/schema/rs.xsd
http://www.oasis-open.org/committees/regrep/documents/3.0/schema/query.xsd
http://www.oasis-open.org/committees/regrep/documents/3.0/schema/lcm.xsd
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ebxmlrr/ebxmlrr-spec/misc/samples/
Copyright © OASIS, 2002. All Rights Reserved
Page 174 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
6008
Appendix C
Interpretation of UML Diagrams
6009
6010
This section describes in abstract terms the conventions used to define ebXML business process
description in UML.
6011
C.1 UML Class Diagram
6012
6013
6014
6015
6016
6017
6018
6019
6020
6021
6022
A UML class diagram is used to describe the Service Interfaces required to implement an
ebXML Registry Services and clients. The UML class diagram contains:
6023
C.2 UML Sequence Diagram
6024
6025
6026
6027
6028
6029
6030
6031
6032
6033
6034
6035
A UML sequence diagram is used to specify the business protocol representing the interactions
between the UML interfaces for a Registry specific ebXML business process. A UML sequence
diagram provides the necessary information to determine the sequencing of messages and request
to response association as well as request to error response association.
Each sequence diagram shows the sequence for a specific conversation protocol as method calls
from the requestor to the responder. Method invocation may be synchronous or asynchronous
based on the UML notation used on the arrowhead for the link. A half arrowhead represents
asynchronous communication. A full arrowhead represents synchronous communication.
Each method invocation may be followed by a response method invocation from the responder to
the requestor to indicate the ResponseName for the previous Request. Possible error response is
indicated by a conditional response method invocation from the responder to the requestor. See
Figure 11 on page 38 for an example.
1. A collection of UML interfaces where each interface represents a Registry Service
interface.
2. Tabular description of methods on each interface where each method represents an
Action (as defined by [ebCPP]) within the Service Interface.
3. One or more parameters for each method. The type of each parameter represents the
ebXML message type that is exchanged as part of the Action corresponding to the
method. Multiple arguments imply multiple payload documents within the body of the
corresponding ebXML message.
Copyright © OASIS, 2002. All Rights Reserved
Page 175 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
6036
Appendix D
SQL Query
6037
D.1 SQL Query Syntax Specification
6038
6039
6040
This section specifies the rules that define the SQL Query syntax as a subset of SQL-92. The
terms enclosed in angle brackets are defined in [SQL] or in [SQL/PSM]. The SQL query syntax
conforms to the <query specification> as well as the additional restrictions identified below:
6041
1. A <select list> may contain at most one <select sublist>.
6042
6043
2. The <select list> must be is a single column whose data type is UUID, from the table in the
<from clause>.
6044
3. A <derived column> may not have an <as clause>.
6045
6046
4. A <table expression> does not contain the optional <group by clause> and <having
clause> clauses.
6047
5. A <table reference> can only consist of <table name> and <correlation name>.
6048
6049
6. A <table reference> does not have the optional AS between <table name> and
<correlation name>.
6050
6051
6052
7. Restricted use of sub-queries is allowed by the syntax as follows. The <in predicate> allows
for the right hand side of the <in predicate> to be limited to a restricted <query
specification> as defined above.
6053
6054
8. The SQL query syntax allows for the use of <sql invoked routines> invocation from
[SQL/PSM] as the RHS of the <in predicate>.
6055
D.2 Non-Normative BNF for Query Syntax Grammar
6056
6057
6058
6059
The following BNF exemplifies the grammar for the registry query syntax. It is provided here as
an aid to implementers. Since this BNF is not based directly on [SQL] it is provided as nonnormative syntax. For the normative syntax rules see Appendix D.1.
sqlQuery ::= SQLSelect ( <SEMICOLON> )? <EOF>
SQLSelect ::= <SELECT> SQLSelectCols <FROM> SQLTableList ( SQLWhere
)? ( SQLOrderBy )?
SQLSelectCols ::= ( <ALL> | <DISTINCT> )* ( ( "*" | SQLLvalueTerm ) )
SQLTableList ::= SQLTableRef ( "," SQLTableRef )*
SQLTableRef ::= ( <ID> ( <ID> )? )
SQLWhere ::= <WHERE> SQLOrExpr
SQLOrExpr ::= SQLAndExpr ( <OR> SQLAndExpr )*
SQLAndExpr ::= SQLNotExpr ( <AND> SQLNotExpr )*
SQLNotExpr ::= ( <NOT> )? SQLCompareExpr
SQLCompareExpr ::= ( SQLIsClause | SQLSumExpr ( SQLCompareExprRight )? )
SQLCompareExprRight ::= ( SQLLikeClause | SQLInClause | SQLCompareOp SQLSumExpr )
Copyright © OASIS, 2002. All Rights Reserved
Page 176 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
SQLCompareOp ::= ( <EQUAL> | <NOTEQUAL> | <NOTEQUAL2> |
<GREATER> | <GREATEREQUAL> | <LESS> |
<LESSEQUAL> )
SQLInClause ::= ( <NOT> )? <IN> "(" SQLLValueListOrProcedureCall ")"
SQLLValueListOrProcedureCall ::= ( ProcedureCall | SQLLValueList )
ProcedureCall ::= <ID> "(" <STRING_LITERAL> ")"
SQLLValueList ::= SQLLValueElement ( "," SQLLValueElement )*
SQLLValueElement ::= ( <NULL> | SQLSumExpr | SQLSelect )
SQLIsClause ::= SQLColRef <IS> ( <NOT> )? <NULL>
SQLLikeClause ::= ( <NOT> )? <LIKE> SQLPattern
SQLPattern ::= ( <STRING_LITERAL> )
SQLColRef ::= SQLLvalue
SQLLvalue ::= ( SQLLvalueTerm )
SQLLvalueTerm ::= <ID> ( <DOT> <ID> )*
SQLSumExpr ::= SQLProductExpr ( ( "+" | "-" ) SQLProductExpr )*
SQLProductExpr ::= SQLUnaryExpr ( ( "*" | "/" ) SQLUnaryExpr )*
SQLUnaryExpr ::= ( ( "+" | "-" ) )? SQLTerm
SQLTerm ::= ( "(" SQLOrExpr ")" | SQLColRef | SQLLiteral )
SQLLiteral ::= ( <STRING_LITERAL> | <INTEGER_LITERAL> |
<FLOATING_POINT_LITERAL> )
SQLOrderBy ::= <ORDER> <BY> SQLOrderByList
SQLOrderByElem ::= SQLColRef ( SQLOrderDirection )?
SQLOrderByList ::= SQLOrderByElem ( "," SQLOrderByElem )*
SQLOrderDirection ::= ( <ASC> | <DESC> )
6060
6061
D.3 Relational Schema For SQL Queries
6062
6063
6064
6065
6066
6067
6068
The normative Relational Schema definition for SQL queries can be found at the following
location on the web:
http://www.oasis-open.org/committees/regrep/documents/3.0/sql/database.sql
The stored procedures that must be supported by the SQL query feature are defined at the following
location on the web:
http://www.oasis-open.org/committees/regrep/documents/3.0/sql/storedProcedures.sql
Copyright © OASIS, 2002. All Rights Reserved
Page 177 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
6069
Appendix E
Security Implementation Guideline
6070
6071
6072
6073
This section provides a suggested blueprint for how security processing may be implemented in
the Registry. It is meant to be illustrative not prescriptive. Registries may choose to have
different implementations as long as they support the default security roles and authorization
rules described in this document.
6074
E.1 Security Concerns
6075
6076
6077
The security risks broadly stem from the following concerns. After a description of these
concerns and potential solutions, we identify the concerns that we address in the current
specification
6078
1. Is the content of the registry (data) trustworthy?
6079
6080
6081
6082
6083
a) How to make sure “what is in the registry” is “what is put there” by the ContentOwner?
This concern can be addressed by ensuring that the publisher is authenticated using
digital signature (Source Integrity), message is not corrupted during transfer using digital
signature (Data Integrity), and the data is not altered by unauthorized subjects based on
access control policy (Authorization)
6084
6085
6086
6087
b) How to protect data while in transmission?
Communication integrity has two ingredients – Data Integrity (addressed in 1a) and Data
Confidentiality that can be addressed by encrypting the data in transmission. How to
protect against a replay attack?
6088
6089
c) Is the content up to date? The versioning as well as any time stamp processing, when
done securely will ensure the “latest content” is guaranteed to be the latest content.
6090
6091
d) How to ensure only bona fide responsible organizations add contents to registry?
Ensuring Source Integrity (as in 1a).
6092
6093
e) How to ensure that bona fide publishers add contents to registry only at authorized
locations? (System Integrity)
6094
6095
f) What if the publishers deny modifying certain content after-the-fact? To prevent this
(Nonrepudiation) audit trails may be kept which contain signed message digests.
6096
g) What if the reader denies getting information from the registry?
6097
6098
2. How to provide selective access to registry content? The broad answer is, by using an access
control policy – applies to (a), (b), and (c) directly.
6099
a) How does a ContentOwner restrict access to the content to only specific registry readers?
6100
b) How can a ContentOwner allow some “partners” (fellow publishers) to modify content?
6101
c) How to provide selective access to partners the registry usage data?
6102
6103
6104
d) How to prevent accidental access to data by unauthorized users? Especially with
hardware or software failure of the registry security components? The solution to this
problem is by having System Integrity.
6105
e) Data confidentiality of RegistryObject
Copyright © OASIS, 2002. All Rights Reserved
Page 178 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
6106
6107
6108
3. How do we make “who can see what” policy itself visible to limited parties, even excluding
the administrator (self & confidential maintenance of access control policy). By making sure
there is an access control policy for accessing the policies themselves.
6109
6110
6111
6112
6113
6114
6115
4. How to transfer credentials? The broad solution is to use credentials assertion (such as being
worked on in Security Assertions Markup Language (SAML)). Currently, Registry does not
support the notion of a session. Therefore, some of these concerns are not relevant to the
current specification.
a) How to transfer credentials (authorization/authentication) to federated registries?
b) How do aggregators get credentials (authorization/authentication) transferred to them?
c) How to store credentials through a session?
6116
E.2 Authentication
6117
1. As soon as a message is received, a User object is created.
6118
6119
2. If the message is signed, it is verified (including the validity of the certificate) and the DN of
the certificate becomes the identity of the User.
6120
6121
3. If the message is not signed, a User instance is created with the role RegistryGuest. This step
is suggested for symmetry and to decouple the rest of the processing.
6122
4. The message is then processed for the Action and the objects it will act on.
6123
E.3 Authorization
6124
6125
6126
6127
For every RegistryObject resource, the Policy Decision Point as defind by [XACML] within the
registry will process the AccessControlPolicy object associated with the RegistryObject resource
to verify that the requestor subject (e.g. User) is permitted to perform the requested action (e.g.
create, update, delete) on the specified resource.
6128
E.4 Registry Bootstrap
6129
6130
6131
When a Registry is newly created, a default User object should be created with the identity of the
Registry Administrator’s certificate DN with a role RegistryAdministrator. This way, any
message signed by the RegistryAdministrator will get all the privileges.
6132
6133
When a Registry is newly created, an instance of AccessControlPolicy is created as the default
AccessControlPolicy.
6134
E.5 Content Submission – Client Responsibility
6135
6136
The Registered User must sign the contents before submission – otherwise the content will be
rejected.
6137
E.6 Content Submission – Registry Responsibility
6138
6139
1. As with any other request, the Registry Client will first be authenticated. In this case, the
User object will get the DN from the certificate.
6140
2. As per the request in the message, the RegistryObject will be created.
Copyright © OASIS, 2002. All Rights Reserved
Page 179 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
6141
3. The RegistryObject is assigned the default AccessControlPolicy.
6142
6143
4. If the Registry Client is not previously registered, the registry may either reject the request or
accept it and implicitly register the Registry Client.
6144
6145
E.7 Content Remove/Deprecate – Client Responsibility
6146
6147
The Registry client must sign the header before submission, for authentication purposes;
otherwise, the request will be rejected
6148
E.8 Content Remove/Deprecate – Registry Responsibility
6149
6150
1. As with any other request, the Registry Client will first be authenticated. In this case, the
User object will get the DN from the certificate.
6151
6152
2. As per the request in the message (remove or deprecate), the appropriate method in the
RegistryObject class will be accessed.
6153
6154
3. The access controller performs the authorization by iterating through the Permission objects
associated with this object via the default AccessControlPolicy.
6155
6156
4. If authorization succeeds then the action will be permitted. Otherwise an error response is
sent back with a suitable AuthorizationException error message.
6157
E.9 Using ds:KeyInfo Field
6158
Two typical usage scenarios for ds:KeyInfo are described below.
6159
Scenario 1
6160
1. Registry Client (RC) signs the payload and the SOAP envelope using its private key.
6161
2. The certificate of RC is passed to the Registry in KeyInfo field of the header signature.
6162
3. The certificate of RC is passed to the Registry in KeyInfo field of the payload signature.
6163
4. Registration Authority retrieves the certificate from the KeyInfo field in the header signature.
6164
6165
5. Registration Authority validates the header signature using the public key from the
certificate.
6166
6167
6168
6169
6. Registration Authority validates the payload signature by repeating steps 4 and 5 using the
certificate from the KeyInfo field of the payload signature. Note that this step is not an
essential one if the onus of validation is that of the eventual user, another Registry Client, of
the content.
6170
Scenario 2
6171
6172
1. RC1 signs the payload and SOAP envelope using its private key and publishes to the
Registry.
6173
2. The certificate of RC1 is passed to the Registry in the KeyInfo field of the header signature.
Copyright © OASIS, 2002. All Rights Reserved
Page 180 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
6174
6175
6176
3. The certificate of RC1 is passed to the Registry in the KeyInfo field of the payload signature.
This step is required in addition to step 2 because when RC2 retrieves content, it should see
RC1’s signature with the payload.
6177
4. RC2 retrieves content from the Registry.
6178
6179
5. Registration Authority signs the SOAP envelope using its private key. Registration Authority
sends RC1’s content and the RC1’s signature (signed by RC1).
6180
6181
6182
6. Registration Authority need not send its certificate in the KeyInfo field sinceRC2 is assumed
to have obtained the Registration Authority’s certificate in an implementation-specific
manner and installed it in its local key store.
6183
6184
7. RC2 obtains Registration Authority’s certificate out of its local key store and verifies the
Registration Authority’s signature.
6185
6186
8. RC2 obtains RC1’s certificate from the KeyInfo field of the payload signature and validates
the signature on the payload.
Copyright © OASIS, 2002. All Rights Reserved
Page 181 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
6187
Appendix F
6188
F.1 Definitions
6189
6190
Although this section discusses only character set and language, the following terms have to be
defined clearly.
6191
F.1.1 Coded Character Set (CCS):
6192
6193
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.
6194
F.1.2 Character Encoding Scheme (CES):
6195
6196
CES is a mapping from a CCS (or several) to a set of octets. [RFC 2130]. Examples of CES are
ISO-2022, UTF-8.
6197
F.1.3 Character Set (charset):
6198
6199
6200
6201
F.2 NLS And Request / Response Messages
6202
6203
6204
6205
6206
6207
6208
6209
6210
For the accurate processing of data in both registry client and registry services, it is essential to
know which character set is used. Although the body part of the transaction may contain the
charset in xml encoding declaration, registry client and registry services shall specify charset
parameter in MIME header when they use text/xml. Because as defined in [RFC 3023], if a
text/xml entity is received with the charset parameter omitted, MIME processors and XML
processors MUST use the default charset value of "us-ascii". For example:
6211
6212
6213
Also, when an application/xml entity is used, the charset parameter is optional, and registry
client and registry services must follow the requirements in Section 4.3.3 of [REC-XML] which
directly address this contingency.
6214
If another Content-Type is used, then usage of charset must follow [RFC 3023].
6215
F.3 NLS And Storing of RegistryObject
6216
This section provides NLS guidelines on how a registry should store RegistryObject instances.
6217
6218
6219
A single instance of a concrete sub-class of RegistryObject is capable of supporting multiple
locales. Thus there is no language or character set associated with a specific RegistryObject
instance.
6220
6221
A single instance of a concrete sub-class of RegistryObject supports multiple locales as follows.
Each attribute of the RegistryObject that is I18N capable (e.g. name and description attributes in
Native Language Support (NLS)
charset is a set of rules for mapping from a sequence 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].
Content-Type: text/xml; charset=ISO-2022-JP
Copyright © OASIS, 2002. All Rights Reserved
Page 182 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
6222
6223
6224
6225
6226
RegistryObject class) as defined by [ebRIM], may have multiple locale specific values expressed
as LocalizedString sub-elements within the XML element representing the I18N capable
attribute. Each LocalizedString sub-element defines the value of the I18N capable attribute in a
specific locale. Each LocalizedString element has a charset and lang attribute as well as a value
attribute of type string.
6227
F.3.1 Character Set of LocalizedString
6228
6229
The character set used by a locale specific String (LocalizedString) is defined by the charset
attribute. It is highly recommended to use UTF-8 or UTF-16 for maximum interoperability.
6230
F.3.2 Language Information of LocalizedString
6231
The language may be specified in xml:lang attribute (Section 2.12 [REC-XML]).
6232
F.4 NLS And Storing of Repository Items
6233
6234
6235
6236
This section provides NLS guidelines on how a registry should store repository items.
While a single instance of an ExtrinsicObject is capable of supporting multiple locales, it is
always associated with a single repository item. The repository item may be in a single locale or
may be in multiple locales. This specification does not specify the repository item.
6237
F.4.1 Character Set of Repository Items
6238
6239
6240
6241
6242
6243
The MIME Content-Type mime header for the mime multipart containing the repository item
MAY contain a charset attribute that specifies the character set used by the repository item. For
example:
6244
6245
It is highly recommended to use UTF-16 or UTF-8 for maximum inter-operability. The charset
of a repository item must be preserved as it is originally specified in the transaction.
6246
F.4.2 Language information of repository item
6247
6248
6249
The Content-language mime header for the mime bodypart containing the repository item may
specify the language for a locale specific repository item. The value of the Content-language
mime header property must conform to [RFC 1766].
6250
6251
6252
6253
6254
This document currently specifies only the method of sending the information of character set
and language, and how it is stored in a registry. However, the language information may be used
as one of the query criteria, such as retrieving only DTD written in French. Furthermore, a
language negotiation procedure, like registry client is asking a favorite language for messages
from registry services, could be another functionality for the future revision of this document.
Content-Type: text/xml; charset="UTF-8"
Copyright © OASIS, 2002. All Rights Reserved
Page 183 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
6255
13 References
6256
6257
6258
6259
6260
6261
6262
6263
6264
6265
6266
6267
6268
6269
6270
6271
6272
6273
6274
6275
6276
6277
6278
6279
6280
6281
6282
6283
6284
6285
6286
6287
6288
6289
6290
6291
6292
[Bra97] Keywords for use in RFCs to Indicate Requirement Levels.
[ebRIM] ebXML Registry Information Model version 3.0
6293
6294
6295
[RFC 3023] ETF (Internet Engineering Task Force). RFC 3023:
XML Media Types, ed. M. Murata. 2001.
6296
6297
[REC-XML] W3C Recommendation. Extensible Markup language(XML)1.0(Second Edition)
http://www.oasis-open.org/committees/regrep/documents/3.0/specs/ebRIM.pdf
[ebRIM Schema] ebXML Registry Information Model Schema
http://www.oasis-open.org/committees/regrep/documents/3.0/schema/rim.xsd
[ebBPSS] ebXML Business Process Specification Schema
http://www.ebxml.org/specs
[ebCPP] ebXML Collaboration-Protocol Profile and Agreement Specification
http://www.ebxml.org/specs/
[ebMS] ebXML Messaging Service Specification, Version 1.0
http://www.ebxml.org/specs/
[XPT] XML Path Language (XPath) Version 1.0
http://www.w3.org/TR/xpath
[SQL] Structured Query Language (FIPS PUB 127-2)
http://www.itl.nist.gov/fipspubs/fip127-2.htm
[SQL/PSM] Database Language SQL — Part 4: Persistent Stored Modules
(SQL/PSM) [ISO/IEC 9075-4:1996]
[IANA] IANA (Internet Assigned Numbers Authority).
Official Names for Character Sets, ed. Keld Simonsen et al.
ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets
[RFC 1766] IETF (Internet Engineering Task Force). RFC 1766:
Tags for the Identification of Languages, ed. H. Alvestrand. 1995.
http://www.cis.ohio-state.edu/htbin/rfc/rfc1766.html
[RFC 2119] IETF (Internet Engineering Task Force). RFC 2119
[RFC 2130] IETF (Internet Engineering Task Force). RFC 2130
[RFC 2277] IETF (Internet Engineering Task Force). RFC 2277:
IETF policy on character sets and languages, ed. H. Alvestrand. 1998.
http://www.cis.ohio-state.edu/htbin/rfc/rfc2277.html
[RFC 2278] IETF (Internet Engineering Task Force). RFC 2278:
IANA Charset Registration Procedures, ed. N. Freed and J. Postel. 1998.
http://www.cis.ohio-state.edu/htbin/rfc/rfc2278.html
[RFC2616] RFC 2616:
Fielding et al. Hypertext Transfer Protocol -- HTTP/1.1 . 1999.
http://www.w3.org/Protocols/rfc2616/rfc2616.html
[RFC 2828] IETF (Internet Engineering Task Force). RFC 2828:
Internet Security Glossary, ed. R. Shirey. May 2000.
http://www.cis.ohio-state.edu/htbin/rfc/rfc2828.html
ftp://ftp.isi.edu/in-notes/rfc3023.txt
http://www.w3.org/TR/REC-xml
Copyright © OASIS, 2002. All Rights Reserved
Page 184 of 188
OASIS/ebXML Registry Services Specification v3.0
6298
6299
6300
[UUID] DCE 128 bit Universal Unique Identifier
6301
6302
6303
6304
6305
6306
6307
6308
[WSDL] W3C Note. Web Services Description Language (WSDL) 1.1
July 2017
http://www.opengroup.org/onlinepubs/009629399/apdxa.htm#tagcjh_20
http://www.opengroup.org/publications/catalog/c706.htmttp://www.w3.org/TR/REC-xml
http://www.w3.org/TR/wsdl
[SOAP11] W3C Note. Simple Object Access Protocol, May 2000,
http://www.w3.org/TR/SOAP
[SOAPAt] W3C Note: SOAP with Attachments, Dec 2000,
http://www.w3.org/TR/SOAP-attachments
[XMLDSIG] XML-Signature Syntax and Processing,
http://www.w3.org/TR/2001/PR-xmldsig-core-20010820/
Copyright © OASIS, 2002. All Rights Reserved
Page 185 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
6309
14 Disclaimer
6310
6311
6312
6313
The views and specification expressed in this document are those of the authors and are not
necessarily those of their employers. The authors and their employers specifically disclaim
responsibility for any problems arising from correct or incorrect implementation or use of this
design.
Copyright © OASIS, 2002. All Rights Reserved
Page 186 of 188
OASIS/ebXML Registry Services Specification v3.0
6314
15 Contact Information
6315
6316
6317
6318
6319
6320
6321
6322
6323
6324
6325
6326
6327
6328
6329
6330
6331
6332
6333
6334
6335
6336
6337
6338
6339
6340
6341
6342
6343
6344
6345
6346
6347
6348
6349
6350
Team Leader
Name:
Company:
Street:
City, State, Postal Code:
Country:
Phone:
Email:
Editor
Name:
Company:
Street:
City, State, Postal Code:
Country:
Phone:
Email:
Kathryn R. Breininger
The Boeing Company
P.O. Box 3707 MC 62-LC
Seattle, WA 98124-2207
USA
425-965-0182
[email protected]
Sally Fuger
Automotive Industry Action Group
26200 Lahser Road, Suite 200
Southfield, MI 48034
USA
(248) 358-9744
[email protected]
Technical Editor
Name:
Company:
Street:
City, State, Postal Code:
Country:
Phone:
Email:
Farrukh S. Najmi
Sun Microsystems
1 Network Dr., MS BUR02-302
Burlington, MA, 01803-0902
USA
(781) 442-0703
[email protected]
Technical Editor
Name:
Company:
Street:
City, State, Postal Code:
Country:
Phone:
Email:
Nikola Stojanovic
Metaspaces Consulting
101 Pineview Terrace
Ithaca, NY, 14850
USA
(607) 273-2224
[email protected]
Copyright © OASIS, 2002. All Rights Reserved
July 2017
Page 187 of 188
OASIS/ebXML Registry Services Specification v3.0
July 2017
6351
16 Copyright Statement
6352
Portions of this document are copyright (c) 2001 OASIS and UN/CEFACT.
6353
6354
6355
6356
6357
6358
6359
6360
6361
6362
6363
6364
6365
6366
6367
6368
6369
6370
Copyright (C) The Organization for the Advancement of Structured Information
Standards [OASIS], 2002. All Rights Reserved.
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 paragraph are included on all such copies and derivative works.
However, this document itself may not be modified in any way, such as by removing the
copyright notice or references to OASIS, except as needed for the purpose of developing OASIS
specifications, in which case the procedures for copyrights defined in the OASIS Intellectual
Property Rights document 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 RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
6371
6372
6373
6374
6375
6376
6377
6378
6379
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's procedures with respect to rights in OASIS specifications can be found
at 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
specification, can be obtained from the OASIS Executive Director.
6380
6381
6382
OASIS invites any interested party to bring to its attention any copyrights, patents or patent
applications, or other proprietary rights which may cover technology that may be required to
implement this specification. Please address the information to the OASIS Executive Director.
Copyright © OASIS, 2002. All Rights Reserved
Page 188 of 188
© Copyright 2026 Paperzz