ࡱ > w x y z { | } ~ B D F
} M bjbj== W W l * * * * 4 4 4 &4 x x x 8 y ~ L
&4 7 2 f , w | 5 5 5 5 5 5 5 $ : = Z 5 4 5 , * * 5 , , , 4 * L 4 5 , 5 , , 53 5 - p1 4 . & `&7&4 D x % #" . 6 l 7 % p= ( p= . , &4 &4 * * * *
ebXML Registry Services Specification v1.00.90
ebXML Registry Project Team
101 May23 April 2001
Status of this Document
This document specifies an ebXML DRAFT STANDARD for the eBusiness community.
Distribution of this document is unlimited.
The document formatting is based on the Internet Societys Standard RFC format.
This version:
HYPERLINK " http://www.ebxml.org/specdraftsproject_teams/registry/private/RegistryServicesSpecificationv1.00.89.pdf" http://www.ebxml.org/specdraftsproject_teams/registry/private/ebRSRegistryServicesSpecificationv1.00.89.pdf
Latest version:
HYPERLINK " http://www.ebxml.org/specdraftsproject_teams/registry/private/RegistryServicesSpecificationv1.0.pdf" http://www.ebxml.org/specdraftsproject_teams/registry/private/ebRSRegistryServicesSpecificationv1.0.p.pdf
Previous version:
HYPERLINK " http://www.ebxml.org/project_teams/registry/private/RegistryServicesSpecificationv0.9088.pdf" http://www.ebxml.org/project_teams/registry/private/RegistryServicesSpecificationv0.9088.pdf
ebXML participants
ebXML Registry Services, v1.0 was developed by the ebXML Registry Project Team. At the time this specification was approved, the membership of the ebXML Registry Project Team was as follows:
Lisa Carnahan, NIST
Joe Dalman, Tie
Philippe DeSmedt, Viquity
Sally Fuger, AIAG
Len Gallagher, NIST
Steve Hanna, Sun Microsystems
Scott Hinkelman, IBM
Michael Kass, NIST
Jong.L Kim, Innodigital
Kyu-Chul Lee, Chungnam National University
Sangwon Lim, Korea Institute for Electronic Commerce
Bob Miller, GXS
Kunio Mizoguchi, Electronic Commerce Promotion Council of Japan
Dale Moberg, Sterling Commerce
Ron Monzillo, Sun Microsystems
JP Morgenthal, eThink Systems, Inc.
Joel Munter, Intel
Farrukh Najmi, Sun Microsystems
Scott Nieman, Norstan Consulting
Frank Olken, Lawrence Berkeley National Laboratory
Michael Park, eSum Technologies
Bruce Peat, eProcess Solutions
Mike Rowley, Excelon Corporation
Waqar Sadiq, Vitria
Krishna Sankar, Cisco Systems Inc.
Kim Tae Soo, Government of Korea
Nikola Stojanovic, Encoda Systems, Inc.
David Webber, XML Global
Yutaka Yoshida, Sun Microsystems
Prasad Yendluri, webmethods
Peter Z. Zhoo, Knowledge For the new Millennium
Table of Contents
TOC \o "1-4" 1 Status of this Document PAGEREF _Toc514029901 \h 1
2 ebXML participants PAGEREF _Toc514029902 \h 2
Table of Contents PAGEREF _Toc514029903 \h 3
Table of Tables PAGEREF _Toc514029904 \h 7
3 Introduction PAGEREF _Toc514029905 \h 8
3.1 Summary of Contents of Document PAGEREF _Toc514029906 \h 8
3.2 General Conventions PAGEREF _Toc514029907 \h 8
3.3 Audience PAGEREF _Toc514029908 \h 8
3.4 Related Documents PAGEREF _Toc514029909 \h 8
4 Design Objectives PAGEREF _Toc514029910 \h 9
4.1 Goals PAGEREF _Toc514029911 \h 9
4.2 Caveats and Assumptions PAGEREF _Toc514029912 \h 9
5 System Overview PAGEREF _Toc514029913 \h 9
5.1 What The ebXML Registry Does PAGEREF _Toc514029914 \h 9
5.2 How The ebXML Registry Works PAGEREF _Toc514029915 \h 9
5.2.1 Schema Documents Are Submitted PAGEREF _Toc514029916 \h 10
5.2.2 Business Process Documents Are Submitted PAGEREF _Toc514029917 \h 10
5.2.3 Sellers Collaboration Protocol Profile Is Submitted PAGEREF _Toc514029918 \h 10
5.2.4 Buyer Discovers The Seller PAGEREF _Toc514029919 \h 10
5.2.5 CPA Is Established PAGEREF _Toc514029920 \h 10
5.3 Where the Registry Services May Be Implemented PAGEREF _Toc514029921 \h 11
5.4 Implementation Conformance PAGEREF _Toc514029922 \h 11
5.4.1 Conformance as an ebXML Registry PAGEREF _Toc514029923 \h 11
5.4.2 Conformance as an ebXML Registry Client PAGEREF _Toc514029924 \h 11
6 Registry Architecture PAGEREF _Toc514029925 \h 12
6.1 ebXML Registry Profiles and Agreements PAGEREF _Toc514029926 \h 13
6.2 Client To Registry Communication Bootstrapping PAGEREF _Toc514029927 \h 13
6.3 Interfaces PAGEREF _Toc514029928 \h 14
6.4 Interfaces Exposed By The Registry PAGEREF _Toc514029929 \h 15
6.4.1 Synchronous and Asynchronous Responses PAGEREF _Toc514029930 \h 15
6.4.2 Interface RegistryService PAGEREF _Toc514029931 \h 15
6.4.3 Interface ObjectManager PAGEREF _Toc514029932 \h 16
6.4.4 Interface ObjectQueryManager PAGEREF _Toc514029933 \h 16
6.5 Interfaces Exposed By Registry Clients PAGEREF _Toc514029934 \h 17
6.5.1 Interface RegistryClient PAGEREF _Toc514029935 \h 17
6.6 Registry Response Class Hierarchy PAGEREF _Toc514029936 \h 18
7 Object Management Service PAGEREF _Toc514029939 \h 19
7.1 Life Cycle of a Repository Item PAGEREF _Toc514029940 \h 19
7.2 RegistryObject Attributes PAGEREF _Toc514029941 \h 20
7.3 The Submit Objects Protocol PAGEREF _Toc514029942 \h 20
7.3.1 Universally Unique ID Generation PAGEREF _Toc514029943 \h 21
7.3.2 ID Attribute And Object References PAGEREF _Toc514029944 \h 21
7.3.3 Sample SubmitObjectsRequest PAGEREF _Toc514029945 \h 22
7.4 The Add Slots Protocol PAGEREF _Toc514029946 \h 24
7.5 The Remove Slots Protocol PAGEREF _Toc514029947 \h 24
7.6 The Approve Objects Protocol PAGEREF _Toc514029948 \h 25
7.7 The Deprecate Objects Protocol PAGEREF _Toc514029949 \h 26
7.8 The Remove Objects Protocol PAGEREF _Toc514029950 \h 26
7.8.1 Deletion Scope DeleteRepositoryItemOnly PAGEREF _Toc514029951 \h 27
7.8.2 Deletion Scope DeleteAll PAGEREF _Toc514029952 \h 27
8 Object Query Management Service PAGEREF _Toc514029953 \h 27
8.1 Browse and Drill Down Query Support PAGEREF _Toc514029954 \h 28
8.1.1 Get Root Classification Nodes Request PAGEREF _Toc514029955 \h 28
8.1.2 Get Classification Tree Request PAGEREF _Toc514029956 \h 29
8.1.3 Get Classified Objects Request PAGEREF _Toc514029957 \h 29
8.1.3.1 Get Classified Objects Request Example PAGEREF _Toc514029958 \h 30
8.2 Filter Query Support PAGEREF _Toc514029959 \h 32
8.2.1 FilterQuery PAGEREF _Toc514029960 \h 34
8.2.2 RegistryEntryQuery PAGEREF _Toc514029961 \h 36
8.2.3 AuditableEventQuery PAGEREF _Toc514029962 \h 42
8.2.4 ClassificationNodeQuery PAGEREF _Toc514029963 \h 45
8.2.5 RegistryPackageQuery PAGEREF _Toc514029964 \h 48
8.2.6 OrganizationQuery PAGEREF _Toc514029965 \h 50
8.2.7 ReturnRegistryEntry PAGEREF _Toc514029966 \h 53
8.2.8 ReturnRepositoryItem PAGEREF _Toc514029967 \h 57
8.2.9 Registry Filters PAGEREF _Toc514029968 \h 61
8.2.10 XML Clause Constraint Representation PAGEREF _Toc514029969 \h 65
8.3 SQL Query Support PAGEREF _Toc514029970 \h 69
8.3.1 SQL Query Syntax Binding To [ebRIM] PAGEREF _Toc514029971 \h 69
8.3.1.1 Interface and Class Binding PAGEREF _Toc514029972 \h 69
8.3.1.2 Accessor Method To Attribute Binding PAGEREF _Toc514029973 \h 70
8.3.1.3 Primitive Attributes Binding PAGEREF _Toc514029974 \h 70
8.3.1.4 Reference Attribute Binding PAGEREF _Toc514029975 \h 70
8.3.1.5 Complex Attribute Binding PAGEREF _Toc514029976 \h 70
8.3.1.6 Collection Attribute Binding PAGEREF _Toc514029977 \h 71
8.3.2 Semantic Constraints On Query Syntax PAGEREF _Toc514029978 \h 71
8.3.3 SQL Query Results PAGEREF _Toc514029979 \h 71
8.3.4 Simple Metadata Based Queries PAGEREF _Toc514029980 \h 72
8.3.5 RegistryEntry Queries PAGEREF _Toc514029981 \h 72
8.3.6 Classification Queries PAGEREF _Toc514029982 \h 72
8.3.6.1 Identifying ClassificationNodes PAGEREF _Toc514029983 \h 72
8.3.6.2 Getting Root Classification Nodes PAGEREF _Toc514029984 \h 72
8.3.6.3 Getting Children of Specified ClassificationNode PAGEREF _Toc514029985 \h 73
8.3.6.4 Getting Objects Classified By a ClassificationNode PAGEREF _Toc514029986 \h 73
8.3.6.5 Getting ClassificationNodes That Classify an Object PAGEREF _Toc514029987 \h 73
8.3.7 Association Queries PAGEREF _Toc514029988 \h 73
8.3.7.1 Getting All Association With Specified Object As Its Source PAGEREF _Toc514029989 \h 73
8.3.7.2 Getting All Association With Specified Object As Its Target PAGEREF _Toc514029990 \h 74
8.3.7.3 Getting Associated Objects Based On Association Attributes PAGEREF _Toc514029991 \h 74
8.3.7.4 Complex Association Queries PAGEREF _Toc514029992 \h 74
8.3.8 Package Queries PAGEREF _Toc514029993 \h 74
8.3.8.1 Complex Package Queries PAGEREF _Toc514029994 \h 74
8.3.9 ExternalLink Queries PAGEREF _Toc514029995 \h 74
8.3.9.1 Complex ExternalLink Queries PAGEREF _Toc514029996 \h 75
8.3.10 Audit Trail Queries PAGEREF _Toc514029997 \h 75
8.4 Ad Hoc Query Request/Response PAGEREF _Toc514029998 \h 75
8.5 Content Retrieval PAGEREF _Toc514029999 \h 76
8.5.1 Identification Of Content Payloads PAGEREF _Toc514030000 \h 76
8.5.2 GetContentResponse Message Structure PAGEREF _Toc514030001 \h 76
8.6 Query And Retrieval: Typical Sequence PAGEREF _Toc514030002 \h 77
9 Registry Security PAGEREF _Toc514030003 \h 78
9.1 Integrity of Registry Content PAGEREF _Toc514030004 \h 78
9.1.1 Message Payload Signature PAGEREF _Toc514030005 \h 79
9.2 Authentication PAGEREF _Toc514030006 \h 79
9.2.1 Message Header Signature PAGEREF _Toc514030007 \h 79
9.3 Confidentiality PAGEREF _Toc514030008 \h 79
9.3.1 On-the-wire Message Confidentiality PAGEREF _Toc514030009 \h 79
9.3.2 Confidentiality of Registry Content PAGEREF _Toc514030010 \h 80
9.4 Authorization PAGEREF _Toc514030011 \h 80
9.4.1 Pre-defined Roles For Registry Users PAGEREF _Toc514030012 \h 80
9.4.2 Default Access Control Policies PAGEREF _Toc514030013 \h 80
Appendix A ebXML Registry DTD Definition PAGEREF _Toc514030014 \h 81
Appendix B Interpretation of UML Diagrams PAGEREF _Toc514030017 \h 92
B.1 UML Class Diagram PAGEREF _Toc514030018 \h 92
B.2 UML Sequence Diagram PAGEREF _Toc514030019 \h 93
Appendix C SQL Query PAGEREF _Toc514030020 \h 93
C.1 SQL Query Syntax Specification PAGEREF _Toc514030021 \h 93
C.2 Non-Normative BNF for Query Syntax Grammar PAGEREF _Toc514030022 \h 94
C.3 Relational Schema For SQL Queries PAGEREF _Toc514030023 \h 95
Appendix D Non-normative Content Based Ad Hoc Queries PAGEREF _Toc514030024 \h 102
D.1.1 Automatic Classification of XML Content PAGEREF _Toc514030025 \h 102
D.1.2 Index Definition PAGEREF _Toc514030026 \h 102
D.1.3 Example Of Index Definition PAGEREF _Toc514030027 \h 103
D.1.4 Proposed XML Definition PAGEREF _Toc514030028 \h 103
D.1.5 Example of Automatic Classification PAGEREF _Toc514030029 \h 103
Appendix E Security Implementation Guideline PAGEREF _Toc514030030 \h 103
E.1 Authentication PAGEREF _Toc514030031 \h 104
E.2 Authorization PAGEREF _Toc514030032 \h 104
E.3 Registry Bootstrap PAGEREF _Toc514030033 \h 104
E.4 Content Submission Client Responsibility PAGEREF _Toc514030034 \h 104
E.5 Content Submission Registry Responsibility PAGEREF _Toc514030035 \h 104
E.6 Content Delete/Deprecate Client Responsibility PAGEREF _Toc514030036 \h 105
E.7 Content Delete/Deprecate Registry Responsibility PAGEREF _Toc514030037 \h 105
Appendix F Native Language Support (NLS) PAGEREF _Toc514030038 \h 105
F.1 Definitions PAGEREF _Toc514030039 \h 105
F.1.1 Coded Character Set (CCS): PAGEREF _Toc514030040 \h 105
F.1.2 Character Encoding Scheme (CES): PAGEREF _Toc514030041 \h 105
F.1.3 Character Set (charset): PAGEREF _Toc514030042 \h 106
F.2 NLS And Request / Response Messages PAGEREF _Toc514030043 \h 106
F.3 NLS And Storing of RegistryEntry PAGEREF _Toc514030044 \h 106
F.3.1 Character Set of RegistryEntry PAGEREF _Toc514030045 \h 106
F.3.2 Language Information of RegistryEntry PAGEREF _Toc514030046 \h 106
F.4 NLS And Storing of Repository Items PAGEREF _Toc514030047 \h 107
F.4.1 Character Set of Repository Items PAGEREF _Toc514030048 \h 107
F.4.2 Language information of repository item PAGEREF _Toc514030049 \h 107
Appendix G Terminology Mapping PAGEREF _Toc514030050 \h 107
References PAGEREF _Toc514030051 \h 109
Disclaimer PAGEREF _Toc514030052 \h 110
Contact Information PAGEREF _Toc514030053 \h 111
Copyright Statement PAGEREF _Toc514030054 \h 112
1 Status of this Document 1
2 ebXML participants 2
Table of Contents 3
Table of Tables 7
3 Introduction 8
3.1 Summary of Contents of Document 8
3.2 General Conventions 8
3.3 Audience 8
3.4 Related Documents 8
4 Design Objectives 9
4.1 Goals 9
4.2 Caveats and Assumptions 9
5 System Overview 9
5.1 What The ebXML Registry Does 9
5.2 How The ebXML Registry Works 9
5.2.1 Schema Documents Are Submitted 10
5.2.2 Business Process Documents Are Submitted 10
5.2.3 Sellers Collaboration Protocol Profile Is Submitted 10
5.2.4 Buyer Discovers The Seller 10
5.2.5 CPA Is Established 10
5.3 Where the Registry Services May Be Implemented 11
5.4 Implementation Conformance 11
5.4.1 Conformance as an ebXML Registry 11
5.4.2 Conformance as an ebXML Registry Client 11
6 Registry Architecture 12
6.1 ebXML Registry Profiles and Agreements 13
6.2 Client To Registry Communication Bootstrapping 13
6.3 Interfaces 14
6.4 Interfaces Exposed By The Registry 15
6.4.1 Support For Synchronous Responses 15
6.4.2 Interface RegistryService 15
6.4.3 Interface ObjectManager 15
6.4.4 Interface ObjectQueryManager 16
6.5 Interfaces Exposed By Registry Clients 17
6.5.1 Interface RegistryClient 17
6.6 Registry Response Class Hierarchy 18
7 Object Management Service 19
7.1 Life Cycle of a Repository Item 19
7.2 RegistryObject Attributes 20
7.3 The Submit Objects Protocol 20
7.3.1 Universally Unique ID Generation 21
7.3.2 ID Attribute And Object References 21
7.3.3 Sample SubmitObjectsRequest 22
7.4 The Add Slots Protocol 24
7.5 The Remove Slots Protocol 24
7.6 The Approve Objects Protocol 25
7.7 The Deprecate Objects Protocol 26
7.8 The Remove Objects Protocol 26
7.8.1 Deletion Scope DeleteRepositoryItemOnly 27
7.8.2 Deletion Scope DeleteAll 27
8 Object Query Management Service 28
8.1 Browse and Drill Down Query Support 28
8.1.1 Get Root Classification Nodes Request 28
8.1.2 Get Classification Tree Request 29
8.1.3 Get Classified Objects Request 30
8.1.3.1 Get Classified Objects Request Example 31
8.2 Filter Query Support 33
8.2.1 FilterQuery 35
8.2.2 RegistryEntryQuery 37
8.2.3 AuditableEventQuery 43
8.2.4 ClassificationNodeQuery 46
8.2.5 RegistryPackageQuery 49
8.2.6 OrganizationQuery 51
8.2.7 ReturnRegistryEntry 54
8.2.8 ReturnRepositoryItem 58
8.2.9 Registry Filters 63
8.2.10 XML Clause Constraint Representation 66
8.3 SQL Query Support 70
8.3.1 SQL Query Syntax Binding To [ebRIM] 70
8.3.1.1 Interface and Class Binding 70
8.3.1.2 Accessor Method To Attribute Binding 71
8.3.1.3 Primitive Attributes Binding 71
8.3.1.4 Reference Attribute Binding 71
8.3.1.5 Complex Attribute Binding 71
8.3.1.6 Collection Attribute Binding 72
8.3.2 Semantic Constraints On Query Syntax 72
8.3.3 SQL Query Results 72
8.3.4 Simple Metadata Based Queries 72
8.3.5 RegistryEntry Queries 73
8.3.6 Classification Queries 73
8.3.6.1 Identifying ClassificationNodes 73
8.3.6.2 Getting Root Classification Nodes 73
8.3.6.3 Getting Children of Specified ClassificationNode 73
8.3.6.4 Getting Objects Classified By a ClassificationNode 74
8.3.6.5 Getting ClassificationNodes That Classify an Object 74
8.3.7 Association Queries 74
8.3.7.1 Getting All Association With Specified Object As Its Source 74
8.3.7.2 Getting All Association With Specified Object As Its Target 74
8.3.7.3 Getting Associated Objects Based On Association Attributes 74
8.3.7.4 Complex Association Queries 75
8.3.8 Package Queries 75
8.3.8.1 Complex Package Queries 75
8.3.9 ExternalLink Queries 75
8.3.9.1 Complex ExternalLink Queries 75
8.3.10 Audit Trail Queries 76
8.4 Ad Hoc Query Request/Response 76
8.5 Content Retrieval 77
8.5.1 Identification Of Content Payloads 77
8.5.2 GetContentResponse Message Structure 77
8.6 Query And Retrieval: Typical Sequence 78
9 Registry Security 79
9.1 Integrity of Registry Content 79
9.1.1 Message Payload Signature 79
9.2 Authentication 79
9.2.1 Message Header Signature 80
9.3 Confidentiality 80
9.3.1 On-the-wire Message Confidentiality 80
9.3.2 Confidentiality of Registry Content 80
9.4 Authorization 80
9.4.1 Pre-defined Roles For Registry Users 80
9.4.2 Default Access Control Policies 81
Appendix A Schemas and DTD Definitions 81
A.1 ebXML Error Message 82
A.2 ebXML Registry DTD 83
Appendix B Interpretation of UML Diagrams 93
B.1 UML Class Diagram 93
B.2 UML Sequence Diagram 94
Appendix C SQL Query 94
C.1 SQL Query Syntax Specification 94
C.2 Non-Normative BNF for Query Syntax Grammar 95
C.3 Relational Schema For SQL Queries 96
Appendix D Non-normative Content Based Ad Hoc Queries 103
D.1.1 Automatic Classification of XML Content 103
D.1.2 Index Definition 103
D.1.3 Example Of Index Definition 104
D.1.4 Proposed XML Definition 104
D.1.5 Example of Automatic Classification 104
Appendix E Security Implementation Guideline 104
E.1 Authentication 105
E.2 Authorization 105
E.3 Registry Bootstrap 105
E.4 Content Submission Client Responsibility 105
E.5 Content Submission Registry Responsibility 105
E.6 Content Delete/Deprecate Client Responsibility 106
E.7 Content Delete/Deprecate Registry Responsibility 106
Appendix F Native Language Support (NLS) 106
F.1 Definitions 106
F.1.1 Coded Character Set (CCS): 106
F.1.2 Character Encoding Scheme (CES): 106
F.1.3 Character Set (charset): 107
F.2 NLS And Request / Response Messages 107
F.3 NLS And Storing of RegistryEntry 107
F.3.1 Character Set of RegistryEntry 107
F.3.2 Language Information of RegistryEntry 107
F.4 NLS And Storing of Repository Items 108
F.4.1 Character Set of Repository Items 108
F.4.2 Language information of repository item 108
Appendix G Terminology Mapping 108
References 110
Disclaimer 111
Contact Information 112
Copyright Statement 113
1 Status of this Document 1
2 ebXML participants 2
Table of Contents 3
Table of Tables 7
3 Introduction 8
3.1 Summary of Contents of Document 8
3.2 General Conventions 8
3.3 Audience 8
3.4 Related Documents 8
4 Design Objectives 9
4.1 Goals 9
4.2 Caveats and Assumptions 9
5 System Overview 9
5.1 What The ebXML Registry Does 9
5.2 How The ebXML Registry Works 9
5.2.1 Schema Documents Are Submitted 10
5.2.2 Business Process Documents Are Submitted 10
5.2.3 Sellers Collaboration Protocol Profile Is Submitted 10
5.2.4 Buyer Discovers The Seller 10
5.2.5 CPA Is Established 10
5.3 Where the Registry Services May Be Implemented 11
5.4 Implementation Conformance 11
5.4.1 Conformance as an ebXML Registry 11
5.4.2 Conformance as an ebXML Registry Client 11
6 Registry Architecture 12
6.1 ebXML Registry Profiles and Agreements 13
6.2 Client To Registry Communication Bootstrapping 13
6.3 Interfaces 14
6.4 Interfaces Exposed By The Registry 14
6.4.1 Interface RegistryService 15
6.4.2 Interface ObjectManager 15
6.4.3 Interface ObjectQueryManager 16
6.5 Interfaces Exposed By Registry Clients 17
6.5.1 Interface RegistryClient 17
6.5.2 Interface ObjectManagerClient 17
6.5.3 Interface ObjectQueryManagerClient 19
7 Object Management Service 20
7.1 Life Cycle of a Repository Item 20
7.2 RegistryObject Attributes 21
7.3 The Submit Objects Protocol 21
7.3.1 Universally Unique ID Generation 22
7.3.2 ID Attribute And Object References 22
7.3.3 Sample SubmitObjectsRequest 22
7.4 The Add Slots Protocol 25
7.5 The Remove Slots Protocol 25
7.6 The Approve Objects Protocol 26
7.7 The Deprecate Objects Protocol 26
7.8 The Remove Objects Protocol 27
7.8.1 Deletion Scope DeleteRepositoryItemOnly 27
7.8.2 Deletion Scope DeleteAll 27
8 Object Query Management Service 28
8.1 Browse and Drill Down Query Support 29
8.1.1 Get Root Classification Nodes Request 29
8.1.2 Get Classification Tree Request 30
8.1.3 Get Classified Objects Request 30
8.1.3.1 Get Classified Objects Request Example 31
8.2 Filter Query Support 32
8.2.1 FilterQuery 34
8.2.2 RegistryEntryQuery 36
8.2.3 AuditableEventQuery 42
8.2.4 ClassificationNodeQuery 45
8.2.5 RegistryPackageQuery 48
8.2.6 OrganizationQuery 50
8.2.7 ReturnRegistryEntry 53
8.2.8 ReturnRepositoryItem 57
8.2.9 Registry Filters 61
8.2.10 XML Clause Constraint Representation 64
8.3 SQL Query Support 68
8.3.1 SQL Query Syntax Binding To [ebRIM] 68
8.3.1.1 Interface and Class Binding 68
8.3.1.2 Accessor Method To Attribute Binding 69
8.3.1.3 Primitive Attributes Binding 69
8.3.1.4 Reference Attribute Binding 69
8.3.1.5 Complex Attribute Binding 69
8.3.1.6 Collection Attribute Binding 70
8.3.2 Semantic Constraints On Query Syntax 70
8.3.3 SQL Query Results 70
8.3.4 Simple Metadata Based Queries 70
8.3.5 RegistryEntry Queries 71
8.3.6 Classification Queries 71
8.3.6.1 Identifying ClassificationNodes 71
8.3.6.2 Getting Root Classification Nodes 71
8.3.6.3 Getting Children of Specified ClassificationNode 71
8.3.6.4 Getting Objects Classified By a ClassificationNode 72
8.3.6.5 Getting ClassificationNodes That Classify an Object 72
8.3.7 Association Queries 72
8.3.7.1 Getting All Association With Specified Object As Its Source 72
8.3.7.2 Getting All Association With Specified Object As Its Target 72
8.3.7.3 Getting Associated Objects Based On Association Attributes 72
8.3.7.4 Complex Association Queries 73
8.3.8 Package Queries 73
8.3.8.1 Complex Package Queries 73
8.3.9 ExternalLink Queries 73
8.3.9.1 Complex ExternalLink Queries 73
8.3.10 Audit Trail Queries 74
8.4 Ad Hoc Query Request/Response 74
8.5 Content Retrieval 75
8.5.1 Identification Of Content Payloads 75
8.5.2 GetContentResponse Message Structure 76
8.6 Query And Retrieval: Typical Sequence 76
9 Registry Security 77
9.1 Integrity of Registry Content 77
9.1.1 Message Payload Signature 78
9.2 Authentication 78
9.2.1 Message Header Signature 78
9.3 Confidentiality 78
9.3.1 On-the-wire Message Confidentiality 78
9.3.2 Confidentiality of Registry Content 79
9.4 Authorization 79
9.4.1 Pre-defined Roles For Registry Users 79
9.4.2 Default Access Control Policies 79
Appendix A Schemas and DTD Definitions 80
A.1 ebXML Error Message 80
A.2 ebXML Registry DTD 81
Appendix B Interpretation of UML Diagrams 92
B.1 UML Class Diagram 92
B.2 UML Sequence Diagram 92
Appendix C SQL Query 93
C.1 SQL Query Syntax Specification 93
C.2 Non-Normative BNF for Query Syntax Grammar 94
C.3 Relational Schema For SQL Queries 95
Appendix D Non-normative Content Based Ad Hoc Queries 101
D.1.1 Automatic Classification of XML Content 102
D.1.2 Index Definition 102
D.1.3 Example Of Index Definition 102
D.1.4 Proposed XML Definition 103
D.1.5 Example of Automatic Classification 103
Appendix E Security Implementation Guideline 103
E.1 Authentication 103
E.2 Authorization 104
E.3 Registry Bootstrap 104
E.4 Content Submission Client Responsibility 104
E.5 Content Submission Registry Responsibility 104
E.6 Content Delete/Deprecate Client Responsibility 104
E.7 Content Delete/Deprecate Registry Responsibility 105
Appendix F Native Language Support (NLS) 105
F.1 Definitions 105
F.1.1 Coded Character Set (CCS): 105
F.1.2 Character Encoding Scheme (CES): 105
F.1.3 Character Set (charset): 105
F.2 NLS And Request / Response Messages 105
F.3 NLS And Storing of RegistryEntry 106
F.3.1 Character Set of RegistryEntry 106
F.3.2 Language Information of RegistryEntry 106
F.4 NLS And Storing of Repository Items 106
F.4.1 Character Set of Repository Items 106
F.4.2 Language information of repository item 107
Appendix G Terminology Mapping 107
References 109
Disclaimer 110
Contact Information 111
Copyright Statement 112
Table of Figures
TOC \h \z \c "Figure" HYPERLINK \l "_Toc514030716" Figure 1: Registry Architecture Supports Flexible Topologies PAGEREF _Toc514030716 \h 12
HYPERLINK \l "_Toc514030717" Figure 2: ebXML Registry Interfaces PAGEREF _Toc514030717 \h 14
HYPERLINK \l "_Toc514030718" Figure 3: Registry Reponse Class Hierarchy PAGEREF _Toc514030718 \h 18
HYPERLINK \l "_Toc514030719" Figure 4: Life Cycle of a Repository Item PAGEREF _Toc514030719 \h 20
HYPERLINK \l "_Toc514030720" Figure 5: Submit Objects Sequence Diagram PAGEREF _Toc514030720 \h 20
HYPERLINK \l "_Toc514030721" Figure 7: Add Slots Sequence Diagram PAGEREF _Toc514030721 \h 24
HYPERLINK \l "_Toc514030722" Figure 8: Remove Slots Sequence Diagram PAGEREF _Toc514030722 \h 25
HYPERLINK \l "_Toc514030723" Figure 9: Approve Objects Sequence Diagram PAGEREF _Toc514030723 \h 25
HYPERLINK \l "_Toc514030724" Figure 10: Deprecate Objects Sequence Diagram PAGEREF _Toc514030724 \h 26
HYPERLINK \l "_Toc514030725" Figure 11: Remove Objects Sequence Diagram PAGEREF _Toc514030725 \h 27
HYPERLINK \l "_Toc514030726" Figure 12: Get Root Classification Nodes Sequence Diagram PAGEREF _Toc514030726 \h 28
HYPERLINK \l "_Toc514030727" Figure 14: Get Classification Tree Sequence Diagram PAGEREF _Toc514030727 \h 29
HYPERLINK \l "_Toc514030728" Figure 16: A Sample Geography Classification PAGEREF _Toc514030728 \h 30
HYPERLINK \l "_Toc514030729" Figure 17: Get Classified Objects Sequence Diagram PAGEREF _Toc514030729 \h 31
HYPERLINK \l "_Toc514030730" Figure 19: Example ebRIM Binding PAGEREF _Toc514030730 \h 32
HYPERLINK \l "_Toc514030731" Figure 20: The Clause base structure PAGEREF _Toc514030731 \h 65
HYPERLINK \l "_Toc514030732" Figure 21: Submit Ad Hoc Query Sequence Diagram PAGEREF _Toc514030732 \h 75
HYPERLINK \l "_Toc514030733" Figure 23: Typical Query and Retrieval Sequence PAGEREF _Toc514030733 \h 78
Figure 1: Registry Architecture Supports Flexible Topologies 12
Figure 2: ebXML Registry Interfaces 14
Figure 3: Registry Reponse Class Hierarchy 18
Figure 4: Life Cycle of a Repository Item 19
Figure 5: Submit Objects Sequence Diagram 20
Figure 6: Add Slots Sequence Diagram 24
Figure 7: Remove Slots Sequence Diagram 25
Figure 8: Approve Objects Sequence Diagram 25
Figure 9: Deprecate Objects Sequence Diagram 26
Figure 10: Remove Objects Sequence Diagram 27
Figure 11: Get Root Classification Nodes Sequence Diagram 29
Figure 12: Get Classification Tree Sequence Diagram 30
Figure 14: A Sample Geography Classification 31
Figure 15: Get Classified Objects Sequence Diagram 31
Figure 16: Example ebRIM Binding 33
Figure 17: Submit Ad Hoc Query Sequence Diagram 76
Figure 19: Typical Query and Retrieval Sequence 78
Figure 1: Registry Architecture Supports Flexible Topologies 12
Figure 2: ebXML Registry Interfaces 14
Figure 3: Life Cycle of a Registry Entry 20
Figure 4: Submit Objects Sequence Diagram 21
Figure 5: Add Slots Sequence Diagram 25
Figure 6: Remove Slots Sequence Diagram 25
Figure 7: Approve Objects Sequence Diagram 26
Figure 8: Deprecate Objects Sequence Diagram 27
Figure 9: Remove Objects Sequence Diagram 28
Figure 10: Get Root Classification Nodes Sequence Diagram 29
Figure 11: Get Root Classification Nodes Asynchronous Sequence Diagram 29
Figure 12: Get Classification Tree Sequence Diagram 30
Figure 13: Get Classification Tree Asynchronous Sequence Diagram 30
Figure 14: A Sample Geography Classification 31
Figure 15: Submit Ad Hoc Query Sequence Diagram 75
Figure 16: Submit Ad Hoc Query Asynchronous Sequence Diagram 75
Figure 17: Typical Query and Retrieval Sequence 77
Table of Tables
TOC \h \z \c "Table" HYPERLINK \l "_Toc514030073" Table 1: Terminology Mapping Table PAGEREF _Toc514030073 \h 108
Table 1: Terminology Mapping Table 109
Table 1: Terminology Mapping Table 108
Introduction
Summary of Contents of Document
This document defines the interface to the ebXML Registry Services as well as interaction protocols, message definitions and XML schema.
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.
General Conventions
The following conventions are used throughout this document:
UML diagrams are used as a way to concisely describe concepts. They are not intended to convey any specific Implementation or methodology requirements.
The term repository item is used to refer to an object that has been submitted to a Registry for storage and safekeeping (e.g. an XML document or a DTD). Every repository item is described by a RegistryEntry instance.
The term "RegistryEntry" is used to refer to an object that provides metadata about a repository item.
Capitalized Italic words are defined in the ebXML Glossary.
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].
Audience
The target audience for this specification is the community of software developers who are:
Implementers of ebXML Registry Services
Implementers of ebXML Registry Clients
Related Documents
The following specifications provide some background and related information to the reader:
ebXML Registry Information Model [ebRIM]
ebXML Message Service Specification [ebMS]
ebXML Business Process Specification Schema [ebBPM]
ebXML Collaboration-Protocol Profile and Agreement Specification [ebCPP]
Design Objectives
Goals
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
Caveats and Assumptions
The Registry Services specification is first in a series of phased deliverables. Later versions of the document will include additional functionality planned for future development.
It is assumed that:
Interoperability requirements dictate that the ebXML Message Services Specification is used between an ebXML Registry and an ebXML Registry Client. The use of other communication means is not precluded; however, in those cases interoperability cannot be assumed.Other communication means are outside the scope of this specification.
All access to the Registry content is exposed via the interfaces defined for the Registry Services.
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.
System Overview
What The ebXML Registry Does
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.
How The ebXML Registry Works
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.
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).
Schema Documents Are Submitted
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 ObjectManager service of the Registry described in Section REF _Ref498264666 \r \h 7.3.
Business Process Documents Are Submitted
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 ObjectManager service of the Registry described in Section REF _Ref498264666 \r \h 7.3.
Sellers Collaboration Protocol Profile Is Submitted
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 Registrys flexible Classification capabilities.
Buyer Discovers The Seller
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.
The buyer discovers the sellers CPP and decides to engage in a partnership with the seller.
CPA Is Established
The buyer unilaterally creates a Collaboration Protocol Agreement or CPA as defined by [ebCPP] with the seller using the sellers 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].
Where the Registry Services May Be Implemented
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.
Implementation Conformance
An implementation is a conforming ebXML Registry if the implementation meets the conditions in Section 5.4.1. An implementation is a conforming ebXML Registry Client if the implementation meets the conditions in Section 5.4.2. An implementation is a conforming ebXML Registry and a conforming ebXML Registry Client if the implementation conforms to the conditions of Section 5.4.1 and Section 5.4.2. An implementation shall be a conforming ebXML Registry, a conforming ebXML Registry Client, or a conforming ebXML Registry and Registry Client.
Conformance as an ebXML Registry
An implementation conforms to this specification as an ebXML registry if it meets the following conditions:
Conforms to the ebXML Registry Information Model [ebRIM].
Supports the syntax and semantics of the Registry Interfaces and Security Model.
Supports the defined ebXML Error Message DTD (Appendix A.1)
Supports the defined ebXML Registry DTD (Appendix A.2)
Optionally supports the syntax and semantics of Section 8.3, SQL Query Support.
Conformance as an ebXML Registry Client
An implementation conforms to this specification, as an ebXML Registry Client if it meets the following conditions:
Supports the ebXML CPA and bootstrapping process.
Supports the syntax and the semantics of the Registry Client Interfaces.
Supports the defined ebXML Error Message DTD.
Supports the defined ebXML Registry DTD.
Registry Architecture
The ebXML Registry architecture consists of an ebXML Registry and ebXML Registry Clients. The Registry Client interfaces may be local to the registry or local to the user. REF _Ref508013539 \h Figure 1Figure 1Figure 1Figure 1Figure 1 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 users 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 users view. The Registry Client interfaces communicate with the Registry over the internet in this scenario.
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 current business needs.
Figure SEQ Figure \* ARABIC 1: Registry Architecture Supports Flexible Topologies
Clients communicate with the Registry using the ebXML Messaging Service in the same manner as any two ebXML applications communicating with each other.
Future versions of this specification may provide additional services to explicitly extend the Registry architecture to support distributed registries. However this current version of the specification does not preclude ebXML Registries from cooperating with each other to share information, nor does it preclude owners of ebXML Registries from registering their ebXML registries with other registry systems, catalogs, or directories.
Examples include:
an ebXML Registry of Registries that serves as a centralized registration point;
cooperative ebXML Registries, where registries register with each other in a federation;
registration of ebXML Registries with other Registry systems that act as white pages or yellow pages. The document [ebXML-UDDI] provides an example of ebXML Registries being discovered through a system of emerging white/yellow pages known as UDDI.
ebXML Registry Profiles and Agreements
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.
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 simple URL.
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. These interfaces are described in REF _Ref502258862 \h \* MERGEFORMAT Figure 2Figure 2Figure 2Figure 2Figure 3 and subsequent sections. The definition of the Registry CPP template and a Registry Client CPP template are beyond the scope of this document.
Client To Registry Communication Bootstrapping
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 Registrys 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 clients 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 clients session with the Registry, messages may be exchanged bidirectionally as required by the interaction protocols defined in this specification.
Figure SEQ Figure \* ARABIC 22223: ebXML Registry Interfaces
Interfaces
This specification defines the interfaces exposed by both the Registy (Section 6.4) and the Registry Client (Section 6.5). Figure 2 shows the relationship between the interfaces and the mapping of specific Registy interfaces with specific Registry Client interfaces.
Interfaces Exposed By The Registry
When using the ebXML Messaging Services Specification, ebXML Registry Services elements correspond to Messaging Services elements as follows:
The value of the Service element in the MessageHeader is an ebXML Registry Service interface name (e.g., ObjectManager). 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).
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.
Synchronous and Support For SAsynchronous Responses
All methods on interfaces exposed by the registry return a response messageobject.
Asynchronous response
MessageHeader only;
No registry response element (e.g., AdHocQueryResponse and GetContentResponse).
Synchronous response
MessageHeader;
Registry response element including
a status attribute (success or failure)
an optional ebXML Error.
This response onject should be null if the response will be sent asynchronously. The response will be non-null when a synchronous response is being sent back. The choice of synchronous vs. asynchronous response is made in the [CPA] between the client and the registry.
The ebXML Registry implements the following interfaces as its services (Registry Services).
Interface RegistryService
This is the principal interface implemented by the Registry. It provides the methods that are used by the client to discover service-specific interfaces implemented by the Registry.
Method Summary of RegistryService HYPERLINK "../../../javax/jarr/service/ObjectManager.html" ObjectManager HYPERLINK "../../../javax/jarr/service/RegistryService.html" \l "getObjectManager()" getObjectManager() Returns the ObjectManager interface implemented by the Registry service. HYPERLINK "../../../javax/jarr/service/ObjectQueryManager.html" ObjectQueryManager HYPERLINK "../../../javax/jarr/service/RegistryService.html" \l "getObjectQueryManager()" getObjectQueryManager() Returns the ObjectQueryManager interface implemented by the Registry service.Interface ObjectManager
This is the interface exposed by the Registry Service that implements the Object life cycle 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].
Note that the methods of this interface return a RegistryResponse value. This value should be null when the registry will be delivering the response asynchronously at a later time. In case of a synchronous respone, the RegistryResponse will be non-null and will contain a status attribute (success or failure) and an optional ebXML Error in the event of failure.
Method Summary of ObjectManagerRegistryResponseVoid HYPERLINK "../../../javax/jarr/service/ObjectManager.html" \l "approveObjects(javax.jarr.bindings.ApproveObjectsRequest)" approveObjects( HYPERLINK "../../../javax/jarr/bindings/ApproveObjectsRequest.html" ApproveObjectsRequestreq) Approves one or more previously submitted objects.RegistryResponseVoid HYPERLINK "../../../javax/jarr/service/ObjectManager.html" \l "deprecateObjects(javax.jarr.bindings.DeprecateObjectsRequest)" deprecateObjects( HYPERLINK "../../../javax/jarr/bindings/DeprecateObjectsRequest.html" DeprecateObjectsRequestreq) Deprecates one or more previously submitted objects.RegistryResponseVoid HYPERLINK "../../../javax/jarr/service/ObjectManager.html" \l "removeObjects(javax.jarr.bindings.RemoveObjectsRequest)" removeObjects( HYPERLINK "../../../javax/jarr/bindings/RemoveObjectsRequest.html" RemoveObjectsRequestreq) Removes one or more previously submitted objects from the Registry.RegistryResponsevoid HYPERLINK "../../../javax/jarr/service/ObjectManager.html" \l "submitObjects(javax.jarr.bindings.SubmitObjectsRequest)" submitObjects( HYPERLINK "../../../javax/jarr/bindings/SubmitObjectsRequest.html" SubmitObjectsRequestreq) Submits one or more objects and possibly related metadata such as Associations and Classifications.RegistryResponsevoid HYPERLINK "../../../javax/jarr/service/ObjectManager.html" \l "submitObjects(javax.jarr.bindings.SubmitObjectsRequest)" addSlots( HYPERLINK "../../../javax/jarr/bindings/SubmitObjectsRequest.html" AddSlotsRequestreq) Add slots to one or more registry entries.RegistryResponsevoid HYPERLINK "../../../javax/jarr/service/ObjectManager.html" \l "submitObjects(javax.jarr.bindings.SubmitObjectsRequest)" removeSlots( HYPERLINK "../../../javax/jarr/bindings/SubmitObjectsRequest.html" RemoveSlotsRequestreq) Remove specified slots from one or more registry entries.Interface ObjectQueryManager
This is the interface exposed by the Registry that implements the Object 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 rregistry content and metadata.
Note that the methods of this interface return a value. This value should be null when the registry will be delivering the response asynchronously at a later time.
Method Summary of ObjectQueryManager HYPERLINK "../../../javax/jarr/bindings/GetClassificationTreeResponse.html" GetClassificationTreeResponseRegistryResponse
HYPERLINK "../../../javax/jarr/service/ObjectQueryManager.html" \l "getClassificationTree(javax.jarr.bindings.GetClassificationTreeRequest)" getClassificationTree(
HYPERLINK "../../../javax/jarr/bindings/GetClassificationTreeRequest.html" GetClassificationTreeRequestreq) Returns the ClassificationNode Tree under the ClassificationNode specified in GetClassificationTreeRequest.RegistryResponse HYPERLINK "../../../javax/jarr/bindings/GetClassifiedObjectsResponse.html" GetClassifiedObjectsResponse HYPERLINK "../../../javax/jarr/service/ObjectQueryManager.html" \l "getClassifiedObjects(javax.jarr.bindings.GetClassifiedObjectsRequest)" getClassifiedObjects(
HYPERLINK "../../../javax/jarr/bindings/GetClassifiedObjectsRequest.html" GetClassifiedObjectsRequestreq) Returns a collection of references to RegistryEntries classified under specified ClassificationItem.RegistryResponse HYPERLINK "../../../../../javax/jarr/service/test/service/GetContentResponse.html" GetContentResponse HYPERLINK "../../../../../javax/jarr/service/test/service/ObjectQueryManager.html" \l "getContent()" getContent() Returns the content of the specified Repository Item. The response includes all the content specified in the request as additional payloads within the response message.RegistryResponse HYPERLINK "../../../javax/jarr/bindings/GetRootClassificationNodesResponse.html" GetRootClassificationNodesResponse HYPERLINK "../../../javax/jarr/service/ObjectQueryManager.html" \l "getRootClassificationNodes(javax.jarr.bindings.GetRootClassificationNodesRequest)" getRootClassificationNodes(
HYPERLINK "../../../javax/jarr/bindings/GetRootClassificationNodesRequest.html" GetRootClassificationNodesRequestreq)
Returns all root ClassificationNodes that match the namePattern attribute in GetRootClassificationNodesRequest request.RegistryResponse HYPERLINK "../../../../../javax/jarr/service/test/service/AdhocQueryResponse.html" AdhocQueryResponse HYPERLINK "../../../../../javax/jarr/service/test/service/ObjectQueryManager.html" \l "submitAdhocQuery(javax.jarr.service.test.service.AdhocQueryRequest)" submitAdhocQuery( HYPERLINK "../../../../../javax/jarr/service/test/service/AdhocQueryRequest.html" AdhocQueryRequestreq) Submit an ad hoc query request.Interfaces Exposed By Registry Clients
An ebXML Registry client implements the following interfaces.
Interface RegistryClient
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 discover service-specific interfaces implemented bydeliever 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.
The registry sends all asynchronous responses to successful operations to the onResponse method and it sends all error responses to the onError method.
Method Summary of RegistryClientvoid HYPERLINK "../../../javax/jarr/service/ObjectManagerClient.html" ObjectManagerClientonResponse( HYPERLINK "../../../javax/jarr/bindings/RequestAcceptedResponse.html" RegistryResponseresp) Notifies client that of the response sent by registry to previously submitted request. HYPERLINK "../../../javax/jarr/service/RegistryClient.html" \l "getObjectManagerClient()" getObjectManagerClient() Returns the ObjectManagerClient interface implemented by the client.
Registry Response Class Hierarchy
Since many of the responses from the registry have common attributes they are arranged in the following class hierarchy. This hierarchy is reflected in the registry DTD.
Figure SEQ Figure \* ARABIC 3: Registry Reponse Class Hierarchy
Interface ObjectManagerClient
This is the client callback interface for the ObjectManager service of the Registry. The ObjectManager invokes its methods to notify the client about the results of a previously submitted request from the client to the ObjectManager service.
Method SummaryvoidaddSlotsAccepted( HYPERLINK "../../../javax/jarr/bindings/RequestAcceptedResponse.html" RequestAcceptedResponseresp) Notifies client that a previously submitted AddSlotsRequest was accepted by the Registry.voidaddSlotsError( HYPERLINK "../../../javax/jarr/bindings/EbXMLError.html" ebXMLError error) Notifies client that a previously submitted AddSlotsRequest was not accepted by the Registry due to an error.
Interface ObjectQueryManagerClient
This is the client callback interface for the ObjectQueryManager service of the Registry. The ObjectQueryManager invokes its methods to notify the client about the results of a previously submitted query request from the client to the ObjectQueryManager service.
Method Summaryvoid HYPERLINK "../../../javax/jarr/service/ObjectQueryManagerClient.html" \l "getClassificationTreeAsyncResponse(javax.jarr.bindings.GetClassificationTreeResponse)" getClassificationTreeAsyncResponse(
HYPERLINK "../../../javax/jarr/bindings/GetClassificationTreeResponse.html" GetClassificationTreeResponseresp) Async response for getClassificationTreeAsync request.void HYPERLINK "../../../javax/jarr/service/ObjectQueryManagerClient.html" \l "getClassifiedObjectsAsyncResponse(javax.jarr.bindings.GetClassifiedObjectsResponse)" getClassifiedObjectsAsyncResponse(
HYPERLINK "../../../javax/jarr/bindings/GetClassifiedObjectsResponse.html" GetClassifiedObjectsResponseresp) Async response for getClassifiedObjectsAsync request.
void HYPERLINK "../../../../../javax/jarr/service/test/service/ObjectQueryManagerClient.html" \l "getContentAsyncResponse(javax.jarr.service.test.service.GetContentResponse)" getContentAsyncResponse( HYPERLINK "../../../../../javax/jarr/service/test/service/GetContentResponse.html" GetContentResponseresp) Async response for getContent request.void HYPERLINK "../../../javax/jarr/service/ObjectQueryManagerClient.html" \l "getRootClassificationNodesAsyncResponse(javax.jarr.bindings.GetRootClassificationNodesResponse)" getRootClassificationNodesAsyncResponse(
HYPERLINK "../../../javax/jarr/bindings/GetRootClassificationNodesResponse.html" GetRootClassificationNodesResponseresp) Async response for getRootClassificationNodesAsync request.void HYPERLINK "../../../../../javax/jarr/service/test/service/ObjectQueryManagerClient.html" \l "submitAdhocQueryAsyncResponse(javax.jarr.service.test.service.AdhocQueryResponse)" submitAdhocQueryAsyncResponse( HYPERLINK "../../../../../javax/jarr/service/test/service/AdhocQueryResponse.html" AdhocQueryResponseresp) Async response for submitAdhocQueryAsync request.
Object Management Service
Object Management Service
TThis section defines the ObjectManagement service of the Registry. The Object ??MaManagement Service is a sub-service of the Registry service. It provides the functionality required by RegistryClients to manage the life cycle of repository items (e.g. XML documents required for ebXML business processes). The Object 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.
The minimum security policy for an ebXML registry is to accept content from any client if the content is digitally signed by a certificate issued by a Certificate Authority recognized by the ebXML registry. Submitting Organizations do not have to register prior to submitting content.
Life Cycle of a Repository Item
The main purpose of the ObjectManagement service is to manage the life cycle of repository items.
REF _Ref492804307 \h Figure 4Figure 4Figure 4Figure 4Figure 5 shows the typical life cycle of a repository item. Note that the current version of this specification does not support Object versioning. Object versioning will be added in a future version of this specification.
Figure SEQ Figure \* ARABIC 44445: Life Cycle of a Repository Item
RegistryObject Attributes
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 IntrinsicObject (See REF _Ref514031431 \r \h Appendix AAppendix REF _Ref503534253 \n \h A.2 for details) encapsulate all object metadata attributes defined in [ebRIM] as XML attributes.
The Submit Objects Protocol
This section describes the protocol of the Registry Service that allows a RegistryClient to submit one or more repository items to the repository using the ObjectManager on behalf of a Submitting Organization. It is expressed in UML notation as described in REF _Ref502303647 \r \h Appendix B.
Figure SEQ Figure \* ARABIC 5: Submit Objects Sequence Diagram
Figure SEQ Figure \* ARABIC 57: Submit Objects Sequence Diagram
For details on the schema for the Business documents shown in this process refer to Appendix REF _Ref514031076 \r \h Appendix A REF _Ref503775452 \w \h A.2.
The SubmitObjectRequest message includes a RegistrEntryList element.
The RegistryEntryList element specifies one or more ExtrinsicObjects or other RegistryEntries such as Classifications, Associations, ExternalLinks, or Packages.
An ExtrinsicObject element provides required metadata about the content being submitted to the Registry as defined by [ebRIM]. Note that these standard ExtrinsicObject attributes are separate from the repository item itself, thus allowing the ebXML Registry to catalog objects of any object type.
In the event of success, the registry sends a RegistryResponse with a status of success back to the client with a null value for ebXMLError. In the event of failure, the registry sends a RegistryResponse with a status of failure back to the client with a non-null value for ebXMLError.
Universally Unique ID Generation
As specified by [ebRIM], all objects in the registry have a unique id. The id must be a Universally Unique Identifier (UUID) and must conform to the to the format of a URN that specifies a DCE 128 bit UUID as specified in [UUID].
(e.g. urn:uuid:a2345678-1234-1234-123456789012)
This id is usually generated by the registry. The id attribute for submitted objects may optionally be supplied by the client. 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 honor a client-supplied id and use it as the id attribute of the object in the registry. If the id is found by the registry to not be globally unique, the registry must raise the error condition: send an ebXMLError in response with an InvalidIdError message.
If the client does not supply an id for a submitted object then the registry must generate a universally unique id. Whether the id is generated by the client or whether it is generated by the registry, it must be generated using the DCE 128 bit UUID generation algorithm as specified in [UUID].
ID Attribute And Object References
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 unique 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 id upon submission.
When an object in a SubmitObjectsRequest needs to reference an object that is already in the registry, the request must contain an ObjectRef element 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.
Sample SubmitObjectsRequest
The following example shows several different use cases in a single SubmitObjectsRequest. It does not show the complete ebXML Message with the message header and additional payloads in the message for the repository items.
A SubmitObjectsRequest includes a RegistryEntryList 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.
The Add Slots Protocol
This section describes the protocol of the Registry Service that allows a client to add slots to a previously submitted registry entry using the ObjectManager. Slots provide a dynamic mechanism for extending registry entries as defined by [ebRIM].
Figure SEQ Figure \* ARABIC 77768: Add Slots Sequence Diagram
In the event of success, the registry sends a RegistryResponse with a status of success back to the client. with a null value for ebXMLError. In the event of failure, the registry sends a RegistryResponse with a status of failure back to the client with a non-null value for ebXMLError.client.
The Remove Slots Protocol
This section describes the protocol of the Registry Service that allows a client to remove slots to a previously submitted registry entry using the ObjectManager.
Figure SEQ Figure \* ARABIC 88879: Remove Slots Sequence Diagram
In the event of success, the registry sends a RegistryResponse with a status of success back to the client with a null value for ebXMLError. In the event of failure, the registry sends a RegistryResponse with a status of failure back to the client. with a non-null value for ebXMLError.
The Approve Objects Protocol
This section describes the protocol of the Registry Service that allows a client to approve one or more previously submitted repository items using the ObjectManager. Once a repository item is approved it will become available for use by business parties (e.g. during the assembly of new CPAs and Collaboration Protocol Profiles).
Figure SEQ Figure \* ARABIC 999810: Approve Objects Sequence Diagram
In the event of success, the registry sends a RegistryResponse with a status of success back to the client with a null value for ebXMLError. In the event of failure, the registry sends a RegistryResponse with a status of failure back to the client with a non-null value for ebXMLError..
For details on the schema for the business documents shown in this process refer to REF _Ref514031300 \r \h Appendix A.to Appendix REF _Ref503775452 \w \h A.2.
The Deprecate Objects Protocol
This section describes the protocol of the Registry Service that allows a client to deprecate one or more previously submitted repository items using the ObjectManager. Once an object 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.
Figure SEQ Figure \* ARABIC 101010911: Deprecate Objects Sequence Diagram
In the event of success, the registry sends a RegistryResponse with a status of success back to the client with a null value for ebXMLError. In the event of failure, the registry sends a RegistryResponse with a status of failure back to the client. with a non-null value for ebXMLError.
For details on the schema for the business documents shown in this process refer to REF _Ref514031471 \r \h Appendix AAppendix REF _Ref503775452 \w \h A.2.
The Remove Objects Protocol
This section describes the protocol of the Registry Service that allows a client to remove one or more RegistryEntry instances and/or repository items using the ObjectManager.
The RemoveObjectsRequest message is sent by a client to remove RegistryEntry instances and/or repository items. The RemoveObjectsRequest element includes an XML attribute called deletionScope which is an enumeration that can have the values as defined by the following sections.
Deletion Scope 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.
Deletion Scope DeleteAll
This deletionScope specifies that the request should delete both the RegistryEntry and the repository item for the specified registry entries. Only if all references (e.g. Associations, Classifications, ExternalLinks) to a RegistryEntry have been removed, can that RegistryEntry then be removed using a RemoveObjectsRequest with deletionScope DeleteAll. Attempts to remove a RegistryEntry while it still has references raises an error condition: results in an InvalidRequestError. that is returned within an ebXMLError message sent to the ObjectManagerClient by the ObjectManager.
The remove object protocol is expressed in UML notation as described in REF _Ref502303527 \n \h Appendix B.
Figure SEQ Figure \* ARABIC 1111111012: Remove Objects Sequence Diagram
In the event of success, the registry sends a RegistryResponse with a status of success back to the client with a null value for ebXMLError. In the event of failure, the registry sends a RegistryResponse with a status of failure back to the client. with a non-null value for ebXMLError.
For details on the schema for the business documents shown in this process refer to Appendix REF _Ref503775452 \w \h A.2 A..
Object Query Management Service
This section describes the capabilities of the Registry Service that allow a client (ObjectQueryManagerClient) to search for or query RegistryEntries in the ebXML Registry using the ObjectQueryManager interface of the Registry.
The Registry supports multiple query capabilities. These include the following:
Browse and Drill Down Query
Filtered Query
SQL Query
The browse and drill down query in Section 8.1 and the filtered query mechanism in Section 8.2 SHALL 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 SHALL conform to this document. As such this capability is a normative yet optional capability.
In a future version of this specification, the W3C XQuery syntax may be considered as another query syntax.
Any errors in the query request messages are indicated in the corresponding query response message. Note that for each query request/response there is both a synchronous and asynchronous version of the interaction.
Browse and Drill Down Query Support
The browse and drill drown query style is supported by a set of interaction protocols between the ObjectQueryManagerClient and the ObjectQueryManager. Sections 8.1.1, 8.1.2 and 8.1.3 describe these protocols.
Get Root Classification Nodes Request
An ObjectQueryManagerClient sends this request to get a list of root ClassificationNodes defined in the repository. Root classification nodes are defined as nodes that have no parent. Note that it is possible to specify a namePattern attribute that can filter on the name attribute of the root ClassificationNodes. The namePattern must be specified using a wildcard pattern defined by SQL-92 LIKE clause as defined by [SQL].
Figure SEQ Figure \* ARABIC 1212121113: Get Root Classification Nodes Sequence Diagram
Figure SEQ Figure \* ARABIC 14: Get Root Classification Nodes Asynchronous Sequence Diagram
In the event of success, the registry sends a GetRootClassificationNodeResponse with a status of success back to the client with a null value for ebXMLError. In the event of failure, the registry sends a GetRootClassificationNodeResponse with a status of failure back to the client. with a non-null value for ebXMLError.
For details on the schema for thhe business documents shown in this process refer to REF _Ref514031529 \r \h Appendix AAppendix REF _Ref503775452 \w \h A.2.
Get Classification Tree Request
An ObjectQueryManagerClient sends this request to get the ClassificationNode sub-tree defined in the repository under the ClassificationNodes specified in the request. Note that a GetClassificationTreeRequest can specify an integer attribute called depth to get the sub-tree up to the specified depth. If depth is the default value of 1, then only the immediate children of the specified ClassificationNodeList are returned. If depth is 0 or a negative number then the entire sub-tree is retrieved.
Figure SEQ Figure \* ARABIC 1414141315: Get Classification Tree Sequence Diagram
Figure SEQ Figure \* ARABIC 16: Get Classification Tree Asynchronous Sequence Diagram
In the event of success, the registry sends a GetClassificationTreeResponse with a status of success back to the client with a null value for ebXMLError. In the event of failure, the registry sends a GetClassificationTreeResponse with a status of failure back to the client. with a non-null value for ebXMLError.
For details on the schema for the business documents shown in this process refer to REF _Ref514031569 \r \h Appendix AAppendix REF _Ref503775452 \w \h A.2.
Get Classified Objects Request
An ObjectQueryManagerClient sends this request to get a list of RegistryEntries that are classified by all of the specified ClassificationNodes (or any of their descendants), as specified by the ObjectRefList in the request.
It is possible to get RegistryEntries based on matches with multiple classifications. Note that specifying a ClassificationNode is implicitly specifying a logical OR with all descendants of the specified ClassificationNode.
When a GetClassifiedObjectsRequest is sent to the ObjectQueryManager it should return Objects that are:
Either directly classified by the specified ClassificationNode
Or are directly classified by a descendant of the specified ClassificationNode
Get Classified Objects Request Example
EMBED Word.Picture.8
Figure SEQ Figure \* ARABIC 1616161517: A Sample Geography Classification
Let us say a classification tree has the structure shown in REF _Ref502331368 \h Figure 16Figure 16Figure 16Figure 15Figure 17:
If the Geography node is specified in the GetClassifiedObjectsRequest then the GetClassifiedObjectsResponse should include all RegistryEntries that are directly classified by Geography or North America or US or Asia or Japan or Korea or Europe or Germany.
If the Asia node is specified in the GetClassifiedObjectsRequest then the GetClassifiedObjectsResponse should include all RegistryEntries that are directly classified by Asia or Japan or Korea.
If the Japan and Korea nodes are specified in the GetClassifiedObjectsRequest then the GetClassifiedObjectsResponse should include all RegistryEntries that are directly classified by both Japan and Korea.
If the North America and Asia node is specified in the GetClassifiedObjectsRequest then the GetClassifiedObjectsResponse should include all RegistryEntries that are directly classified by (North America or US) and (Asia or Japan or Korea).
Figure SEQ Figure \* ARABIC 17: Get Classified Objects Sequence Diagram
Figure SEQ Figure \* ARABIC : Get Classified Objects Sequence Diagram
In the event of success, the registry sends a GetClassifiedObjectsResponse with a status of success back to the client with a null value for ebXMLError. In the event of failure, the registry sends a GetClassifiedObjectsResponse with a status of failure back to the client. with a non-null value for ebXMLError.
Filter Query Support
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 defined by the ebXML Registry Information Model (ebRIM). The result of such a query is a set of identifiers for instances of that class. A FilterQuery may be a stand-alone query or it may be the initial action of a ReturnRegistryEntry query or a ReturnRepositoryItem query.
A client submits a FilterQuery, a ReturnRegistryEntry query, or a ReturnRepositoryItem query to the ObjectQueryManager as part of an AdhocQueryRequest. The ObjectQueryManager sends an AdhocQueryResponse back to the client, enclosing the appropriate FilterQueryResponse, ReturnRegistryEntryResponse, or ReturnRepositoryItemResponse specified herein. The sequence diagrams for AdhocQueryRequest and AdhocQueryResponse are specified in Section REF _Ref509063806 \r \h 8.48.48.48.4.
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 CX be a class, let Y and Z be classes that have direct associations to CX, and let V be a class that is associated with Z. The ebRIM Binding for CX might be as in REF _Ref512417336 \h Figure 19Figure 19Figure 19Figure 17Figure 15.
Figure SEQ Figure \* ARABIC 1919191715: Example ebRIM Binding
Label1 identifies an association from CX to Y, Label2 identifies an association from CX 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 an CXQuery. The Y node in the tree is limited to the set of Y instances that are linked to CX 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.
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. The supported class filters are specified in Section REF _Ref508519352 \n 8.2.98.2.98.2.98.2.9 and the supported predicate clauses are defined in Section REF _Ref508519378 \n 8.2.108.2.108.2.108.2.10. 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 root node instances that support such a branch.
In the above example, the CXQuery element will have three subelements, one an CXFilter on the CX class to eliminate CX instances that do not satisfy the predicate of the CXFilter, another a YFilter on the Y class to eliminate branches from CX to Y where the target of the association does not satisfy the YFilter, and a third to eliminate branches along a path from CX through Z to V. The third element is called a branch element because it allows class filters on each class along the path from X 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 terminal class in the path.
If an association from a class CX to a class Y is one-to-zero or one-to-one, then at most one branch or filter element on Y is allowed. However, if the association is one-to-many, then multiple filter or branch elements are allowed. This allows one to specify that an instance of CX must have associations with multiple instances of Y before the instance of CX is said to satisfy the branch element.
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.
Support for FilterQuery is required of every conforming ebXML Registry implementation, but other query options are possible. The Registry will hold a self-describing CPP that identifies all supported AdhocQuery options. This profile is described in Section REF _Ref512853021 \n 6.1.
The ebRIM Binding paragraphs in Sections REF _Ref508519268 \n 8.2.28.2.28.2.28.2.2 through REF _Ref508519296 \n 8.2.68.2.68.2.68.2.6 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.
The ReturnRegistryEntry and ReturnRepositoryItem services defined below provide a way to structure an XML document as an expansion of the result of a RegistryEntryQuery. The ReturnRegistryEntry element specified in Section REF _Ref513947886 \r 8.2.7 REF _Ref508519405 \n Error! Reference source not found.8.2.7 allows one to specify what metadata one wants returned with each registry entry identified in the result of a RegistryEntryQuery. The ReturnRepositoryItem specified in Section REF _Ref513947927 \r 8.2.8 REF _Ref508519430 \n Error! Reference source not found.8.2.8 allows one to specify what repository items one wants returned based on their relationships to the registry entries identified by the result of a RegistryEntryQuery.
FilterQuery
Purpose
To identify a set of registry instances from a specific registry class. Each alternative assumes a specific binding to ebRIM. The query result for each query alternative is a set of references to instances of the root class specified by the binding. The SstatusResult is a success indication or a collection of warnings and/or exceptions.
Definition
Semantic Rules
The semantic rules for each FilterQuery alternative are specified in subsequent subsections.
Each FilterQueryResult is a set of XML reference 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 as follows:
objectID is the value of the ID attribute of the RegistryObject class,
objectURN and orgURN are URN values derived from the object ID,
contentURI is a URL value derived from the contentURI attribute of the RegistryEntry class,
timestamp is a literal value to represent the value of the timestamp attribute of the AuditableEvent class.
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 query result 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.
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 query result 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.
If any exception or warning results, then it is returned as the appropriate alternative of the StatusResult element. In an ebXML Message Services environment, Exceptions and Warnings will map to an ErrorList element as specified by [ebTRP]. See Appendix A.1.
RegistryEntryQuery
Purpose
To identify a set of registry entry instances as the result of a query over selected registry metadata.
ebRIM Binding
Definition
Semantic Rules
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.
If a RegistryEntryFilter is not specified, or if RE is empty, then continue below; otherwise, let x be a registry entry in RE. If x does not satisfy the RegistryEntryFilter as defined in Section REF _Ref508521172 \n 8.2.98.2.98.2.98.2.9, then remove x from RE.
If a SourceAssociationBranch element is not specified, or if RE is empty, then continue below; otherwise, let x be a remaining registry entry in RE. If x is not the source object of some Association instance, then remove x from RE; otherwise, treat each SourceAssociationBranch element separately as follows:
If no AssociationFilter is specified within 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 RE. If no RegistryEntryFilter is specified within SourceAssociationBranch, then let RET be the set of all RegistryEntry instances that are the target object of some element of AF; otherwise, let RET be the set of RegistryEntry instances that satisfy the RegistryEntryFilter and are the target object of some element of AF. If RET is empty, then remove x from RE.
If a TargetAssociationBranch element is not specified, or if RE is empty, then continue below; otherwise, let x be a remaining registry entry in RE. If x is not the target object of some Association instance, then remove x from RE; otherwise, treat each TargetAssociationBranch element separately as follows:
If no AssociationFilter is specified within 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 RE. If no RegistryEntryFilter is specified within TargetAssociationBranch, then let RES be the set of all RegistryEntry instances that are the source object of some element of AF; otherwise, let RES be the set of RegistryEntry instances that satisfy the RegistryEntryFilter and are the source object of some element of AF. If RES is empty, then remove x from RE.
If a HasClassificationBranch element is not specified, or if RE is empty, then continue below; otherwise, let x be a remaining registry entry in RE. If x is not the source object of some Classification instance, then remove x from RE; otherwise, treat each HasClassificationBranch element separately as follows:
If no ClassificationFilter is specified within the HasClassificationBranch, then let CL be the set of all Classification instances that have x as a source object; otherwise, let CL be the set of Classification instances that satisfy the ClassificationFilter and have x as the source object. If CL is empty, then remove x from RE. If no ClassificationNodeFilter is specified within HasClassificationBranch, then let CN be the set of all ClassificationNode instances that are the target object of some element of CL; otherwise, let CN be the set of RegistryEntry instances that satisfy the ClassificationNodeFilter and are the target object of some element of CL. If CN is empty, then remove x from RE.
If a SubmittingOrganizationBranch element is not specified, or if RE is empty, then continue below; otherwise, let x be a remaining registry entry in RE. If x does not have a submitting organization, then remove x from RE. If no OrganizationFilter is specified within SubmittingOrganizationBranch, then let SO be the set of all Organization instances that are the submitting organization for x; otherwise, let SO be the set of Organization instances that satisfy the OrganizationFilter and are the submitting organization for x. If SO is empty, then remove x from RE. If no ContactFilter is specified within SubmittingOrganizationBranch, then let CT be the set of all Contact instances that are the contacts for some element of SO; otherwise, let CT be the set of Contact instances that satisfy the ContactFilter and are the contacts for some element of SO. If CT is empty, then remove x from RE.
If a ResponsibleOrganizationBranch element is not specified, or if RE is empty, then continue below; otherwise, let x be a remaining registry entry in RE. If x does not have a responsible organization, then remove x from RE. If no OrganizationFilter is specified within ResponsibleOrganizationBranch, then let RO be the set of all Organization instances that are the responsible organization for x; otherwise, let RO be the set of Organization instances that satisfy the OrganizationFilter and are the responsible organization for x. If RO is empty, then remove x from RE. If no ContactFilter is specified within SubmittingOrganizationBranch, then let CT be the set of all Contact instances that are the contacts for some element of RO; otherwise, let CT be the set of Contact instances that satisfy the ContactFilter and are the contacts for some element of RO. If CT is empty, then remove x from RE.
If an ExternalLinkFilter element is not specified, or if RE is empty, then continue below; otherwise, let x be a remaining registry entry in RE. If x is not linked to some ExternalLink instance, then remove x from RE; otherwise, treat each ExternalLinkFilter element separately as follows:
Let EL be the set of ExternalLink instances that satisfy the ExternalLinkFilter and are linked to x. If EL is empty, then remove x from RE.
If an ExternalIdentifierFilter element is not specified, or if RE is empty, then continue below; otherwise, let x be a remaining registry entry in RE. If x is not linked to some ExternalIdentifier instance, then remove x from RE; 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 RE.
If a SlotFilter element is not specified, or if RE is empty, then continue below; otherwise, let x be a remaining registry entry in RE. If x is not linked to some Slot instance, then remove x from RE; otherwise, treat each SlotFilter element separately as follows:
Let SL be the set of Slot instances that satisfy the SlotFilter and are linked to x. If SL is empty, then remove x from RE.
If a HasAuditableEventBranch element is not specified, or if RE is empty, then continue below; otherwise, let x be a remaining registry entry in RE. If x is not linked to some AuditableEvent instance, then remove x from RE; otherwise, treat each HasAuditableEventBranch element separately as follows:
If an AuditableEventFilter is not specified within HasAuditableEventBranch, then let AE be the set of all AuditableEvent instances for x; otherwise, let AE be the set of AuditableEvent instances that satisfy the AuditableEventFilter and are auditable events for x. If AE is empty, then remove x from RE. If a UserFilter is not specified within HasAuditableEventBranch, then let AI be the set of all User instances linked to an element of AE; otherwise, let AI be the set of User instances that satisfy the UserFilter and are linked to an element of AE.
If AI is empty, then remove x from RE. If an OrganizationFilter is not specified within HasAuditableEventBranch, then let OG be the set of all Organization instances that are linked to an element of AI; otherwise, let OG be the set of Organization instances that satisfy the OrganizationFilter and are linked to an element of AI. If OG is empty, then remove x from RE.
If RE is empty, then raise the warning: registry entry query result is empty.
; Return RE as the result of the RegistryEntryQuery.Return any accumulated warnings or exceptions as the StatusResult associated with the RegistryEntryQuery.
Examples
A client wants 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 superceded, replaced, deprecated, or withdrawn items.
status EQUAL "Approved" -- code by Clause, Section REF _Ref509119034 \n \h 8.2.108.2.108.2.108.2.10
name CONTAINS "XYZ" -- code by Clause, Section REF _Ref509119034 \n \h 8.2.108.2.108.2.108.2.10
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 party profile documents in the Registry, and that each profile has been classified by the products the company deals with. The following query returns a set of registry entry identifiers for profiles of companies that deal with integrated circuit components.
objectType EQUAL "CPP" AND -- code by Clause, Section REF _Ref509119034 \n \h 8.2.108.2.108.2.108.2.10
status EQUAL "Approved"
id STARTSWITH "urn:un:spsc:321118" -- code by Clause, Section REF _Ref509119034 \n \h 8.2.108.2.108.2.108.2.10
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. The root nodes of each scheme are identified by "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/Automotive" and by "Geography/Asia/Japan".
id STARTSWITH "urn:ebxml:cs:industry" AND
path EQUAL "Industry/Automotive" -- code by Clause, Section REF _Ref509119034 \n \h 8.2.108.2.108.2.108.2.10
id STARTSWITH "urn:ebxml:cs:geography" AND
path EQUAL "Geography/Asia/Japan" -- code by Clause, Section REF _Ref509119034 \n \h 8.2.108.2.108.2.108.2.10
A client application wishes to identify all registry Package instances that have a given registry entry as a member of the package. The following query identifies all registry packages that contain the registry entry identified by URN "urn:path:myitem" as a member:
objectType EQUAL "RegistryPackage" -- code by Clause, Section REF _Ref509119034 \n \h 8.2.108.2.108.2.108.2.10
-- code by Clause, Section REF _Ref509119034 \n \h 8.2.108.2.108.2.108.2.10
associationType EQUAL "HasMember" AND
targetObject EQUAL "urn:path:myitem"
A client application wishes to identify all ClassificationNode instances that have some given keyword as part of their name or description. The following query identifies all registry classification nodes that contain the keyword "transistor" as part of their name or as part of their description.
ObjectType="ClassificationNode" AND
(name CONTAINS "transistor" OR -- code by Clause, Section REF _Ref509119034 \n \h 8.2.108.2.108.2.108.2.10
description CONTAINS "transistor")
AuditableEventQuery
Purpose
To identify a set of auditable event instances as the result of a query over selected registry metadata.
ebRIM Binding
Definition
Semantic Rules
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.
If an AuditableEventFilter is not specified, or if AE is empty, then continue below; otherwise, let x be an auditable event in AE. If x does not satisfy the AuditableEventFilter as defined in Section REF _Ref509119291 \n \h 8.2.98.2.98.2.98.2.9, then remove x from AE.
If a RegistryEntryQuery element is not specified, or if AE is empty, then continue below; otherwise, let x be a remaining auditable event in AE. Treat each RegistryEntryQuery element separately as follows:
Let RE be the result set of the RegistryEntryQuery as defined in Section REF _Ref508521405 \n 8.2.28.2.28.2.28.2.2. If x is not an auditable event for some registry entry in RE, then remove x from AE.
If an InvokedByBranch element is not specified, or if AE is empty, then continue below; otherwise, let x be a remaining auditable event in AE.
Let u be the user instance that invokes x. If a UserFilter element is specified within the InvokedByBranch, and if u does not satisfy that filter, then remove x from AE; otherwise, continue below.
If an OrganizationQuery element is not specified within the InvokedByBranch, then continue below; otherwise, let OG be the set of Organization instances that are identified by the organization attribute of u and are in the result set of the OrganizationQuery. If OG is empty, then remove x from AE.
If AE is empty, then raise the warning: auditable event query result is empty.
Return AE as the result of the AuditableEventQuery.
Return any accumulated warnings or exceptions as the StatusResult associated with the AuditableEventQuery.
Examples
A Registry client has registered an item and it has been assigned a URN identifier "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 identifiers for all such events.
timestamp GE "2001-01-01" AND -- code by Clause, Section REF _Ref509119034 \n \h 8.2.108.2.108.2.108.2.10
registryEntry EQUAL "urn:path:myitem"
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 and for which myorg is the responsible organization.
id EQUAL "urn:somepath:myorg" -- code by Clause, Section REF _Ref508521510 \n 8.2.108.2.108.2.108.2.10
id EQUAL "urn:somepath:myorg" -- code by Clause, Section REF _Ref509119034 \n \h 8.2.108.2.108.2.108.2.10
id -EQUAL "urn:somepath:myorg" -- code by Clause, Section REF _Ref509119034 \n \h 8.2.108.2.108.2.108.2.10
ClassificationNodeQuery
Purpose
To identify a set of classification node instances as the result of a query over selected registry metadata.
ebRIM Binding
Definition
Semantic Rules
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.
If a ClassificationNodeFilter is not specified, or if CN is empty, then continue below; otherwise, let x be a classification node in CN. If x does not satisfy the ClassificationNodeFilter as defined in Section REF _Ref509119346 \n \h 8.2.98.2.98.2.98.2.9, then remove x from AE.
If a PermitsClassificationBranch element is not specified, or if CN is empty, then continue below; otherwise, let x be a remaining classification node in CN. If x is not the target object of some Classification instance, then remove x from CN; otherwise, treat each PermitsClassificationBranch element separately as follows:
If no ClassificationFilter is specified within the PermitsClassificationBranch element, then let CL be the set of all Classification instances that have x as the target object; otherwise, let CL be the set of Classification instances that satisfy the ClassificationFilter and have x as the target object. If CL is empty, then remove x from CN. If no RegistryEntryQuery is specified within the PermitsClassificationBranch element, then let RES be the set of all RegistryEntry instances that are the source object of some classification instance in CL; otherwise, let RE be the result set of the RegistryEntryQuery as defined in Section REF _Ref508521405 \n 8.2.28.2.28.2.28.2.2 and let RES be the set of all instances in RE that are the source object of some classification in CL. If RES is empty, then remove x from CN.
If a HasParentNode element is not specified, or if CN is empty, then continue below; 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 root node), then remove x from CN. Let p be the parent node of n. If a ClassificationNodeFilter element is directly contained in HasParentNode and if p does not satisfy the ClassificationNodeFilter, then remove x from CN.
If another HasParentNode element is directly contained within this HasParentNode element, then repeat the previous paragraph with n=p.
If a HasSubnode element is not specified, or if CN is empty, then continue below; 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; otherwise, treat each HasSubnode element separately and execute the following paragraph with n = x.
Let n be a classification node instance. If a ClassificationNodeFilter is not specified within the HasSubnode 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; otherwise, let y be an element of CNC and continue with the next paragraph.
If the HasSubnode element is terminal, i.e. if it does not directly contain another HasSubnode element, then continue below; otherwise, repeat the previous paragraph with the new HasSubnode element and with n = y.
If CN is empty, then raise the warning: classification node query result is empty.
Return CN as the result of the ClassificationNodeQuery.
Return any accumulated warnings or exceptions as the StatusResult associated with the ClassificationNodeQuery
.
Examples
A client application wishes to identify all classification nodes defined in the Registry that are root nodes and have a name that contains the phrase product code or the phrase product type. Note: By convention, if a classification node has no parent (i.e. is a root node), then the parent attribute of that instance is set to null and is represented as a literal by a zero length string.
(name CONTAINS product code OR -- code by Clause, Section REF _Ref508521510 \n 8.2.108.2.108.2.108.2.10
name CONTAINS product type) AND
parent EQUAL
A client application wishes to identify all of the classification nodes at the third level of a classification scheme hierarchy. The client knows that the URN identifier for the root node is urn:ebxml:cs:myroot. The following query identifies all nodes at the second level under myroot (i.e. third level overall).
id EQ urn:ebxml:cs:myroot -- code by Clause, Section REF _Ref508521510 \n 8.2.108.2.108.2.108.2.10
RegistryPackageQuery
Purpose
To identify a set of registry package instances as the result of a query over selected registry metadata.
ebRIM Binding
Definition
Semantic Rules
Let RP denote the set of all persistent Package instances in the Registry. The following steps will eliminate instances in RP that do not satisfy the conditions of the specified filters.
If a PackageFilter is not specified, or if RP is empty, then continue below; otherwise, let x be a package instance in RP. If x does not satisfy the PackageFilter as defined in Section REF _Ref508588281 \n \h 8.2.98.2.98.2.98.2.9, then remove x from RP.
If a HasMemberBranch element is not directly contained in the RegistryPackageQuery, or if RP is empty, then continue below; otherwise, let x be a remaining package instance in RP. If x is an empty package, then remove x from RP; otherwise, treat each HasMemberBranch element separately as follows:
If a RegistryEntryQuery element is not directly contained in the HasMemberBranch element, then let PM be the set of all RegistryEntry instances that are members of the package x; otherwise, let RE be the set of RegistryEntry instances returned by the RegistryEntryQuery as defined in Section REF _Ref508521405 \n \* MERGEFORMAT 8.2.28.2.28.2.28.2.2 and let PM be the subset of RE that are members of the package x. If PM is empty, then remove x from RP.
If RP is empty, then raise the warning: registry package query result is empty.
Return RP as the result of the RegistryPackageQuery.
Return any accumulated warnings or exceptions as the StatusResult associated with the RegistryPackageQuery.
Examples
A client application wishes to identify all package instances in the Registry that contain an Invoice extrinsic object as a member of the package.
objectType EQ Invoice -- code by Clause, Section REF _Ref508521510 \n 8.2.108.2.108.2.108.2.10
A client application wishes to identify all package instances in the Registry that are not empty.
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.
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.
OrganizationQuery
Purpose
To identify a set of organization instances as the result of a query over selected registry metadata.
ebRIM Binding
Definition
Semantic Rules
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.
If an OrganizationFilter element is not directly contained in the OrganizationQuery element, or if ORG is empty, then continue below; otherwise, let x be an organization instance in ORG. If x does not satisfy the OrganizationFilter as defined in Section REF _Ref508588281 \n \h 8.2.98.2.98.2.98.2.9, then remove x from RP.
If a SubmitsRegistryEntry element is not specified within the OrganizationQuery, or if ORG is empty, then continue below; otherwise, consider each SubmitsRegistryEntry element separately as follows:
If no RegistryEntryQuery is specified within the SubmitsRegistryEntry element, then let RES be the set of all RegistryEntry instances that have been submitted to the Registry by organization x; otherwise, let RE be the result of the RegistryEntryQuery as defined in Section REF _Ref508521405 \n 8.2.28.2.28.2.28.2.2 and let RES be the set of all instances in RE that have been submitted to the Registry by organization x. If RES is empty, then remove x from ORG.
If a HasParentOrganization element is not specified within the OrganizationQuery, or if ORG is empty, then continue below; otherwise, execute the following paragraph with o = x:
Let o be an organization instance. If an OrganizationFilter is not specified within the HasParentOrganization 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 another HasParentOrganization element is directly contained within this HasParentOrganization element, then repeat the previous paragraph with o = p.
If an InvokesEventBranch element is not specified within the OrganizationQuery, or if ORG is empty, then continue below; otherwise, consider each InvokesEventBranch element separately as follows:
If an UserFilter is not specified, and if x is not the submitting organization of some AuditableEvent instance, then remove x from ORG. If an AuditableEventFilter is not specified, then let AE be the set of all AuditableEvent instances that have x as the submitting organization; otherwise, let AE be the set of AuditableEvent instances that satisfy the AuditableEventFilter and have x as the submitting organization. If AE is empty, then remove x from ORG. If a RegistryEntryQuery is not specified in the InvokesEventBranch element, then let RES be the set of all RegistryEntry instances associated with an event in AE; otherwise, let RE be the result set of the RegistryEntryQuery, as specified in Section REF _Ref508595989 \n \h 8.2.28.2.28.2.28.2.2, and let RES be the subset of RE of entries submitted by x. If RES is empty, then remove x from ORG.
If a ContactFilter is not specified within the OrganizationQuery, or if ORG is empty, then continue below; otherwise, consider each ContactFilter separately as follows:
Let CT be the set of Contact instances that satisfy the ContactFilter and are the contacts for organization x. If CT is empty, then remove x from ORG.
If ORG is empty, then raise the warning: organization query result is empty.
Return ORG as the result of the OrganizationQuery.
Return any accumulated warnings or exceptions as the StatusResult associated with the OrganizationQuery.
Examples
A client application wishes to identify a set of organizations, based in France, that have submitted a PartyProfile extrinsic object this year.
country EQUAL France -- code by Clause, Section REF _Ref508521510 \n 8.2.108.2.108.2.108.2.10
objectType EQUAL CPP -- code by Clause, Section REF _Ref508521510 \n 8.2.108.2.108.2.108.2.10
timestamp GE 2001-01-01 -- code by Clause, Section REF _Ref508521510 \n 8.2.108.2.108.2.108.2.10
A client application wishes to identify all organizations that have XYZ, Corporation as a parent. The client knows that the URN for XYZ, Corp. is urn:ebxml:org:xyz, but there is no guarantee that subsidiaries of XYZ have a URN that uses the same format, so a full query is required.
id EQUAL urn:ebxml:org:xyz -- code by Clause, Section REF _Ref508521510 \n 8.2.108.2.108.2.108.2.10
ReturnRegistryEntry
Purpose
To construct an XML document that contains selected registry metadata associated with the registry entries identified by a RegistryEntryQuery. NOTE: Initially, the RegistryEntryQuery could be the URN identifier for a single registry entry.
Definition
Semantic Rules
The RegistryEntry, Classification, Association, AuditableEvent, and ExternalLink elements contained in the ReturnRegistryEntryResult are defined by the ebXML Registry DTD specified in Appendix A.2.
Execute the RegistryEntryQuery according to the Semantic Rules specified in Section REF _Ref508521717 \n 8.2.28.2.28.2.28.2.2, and let R be the result set of identifiers for registry entry instances. Let S be the set of warnings and errorsstatus elements returned. in the StatusResult. If any status element in S is an exception error condition, then stop execution and return the same StatusResult elementset of warnings and errors along with in the ReturnRegistryEntryResult.
If the set R is empty, then do not return a RegistryEntryMetadata subelement in the ReturnRegistryEntryResult. Instead, raise the warning: no resulting registry entry. Add this warning to the StatusResult error list returned by the RegistryEntryQuery and return this enhanced StatusResult error list with the ReturnRegistryEntryResult.
For each registry entry E referenced by an element of R, use the attributes of E to create a new RegistryEntry element as defined in Appendix A.2.A. Then create a new RegistryEntryMetadata element as defined above to be the parent element of that RegistryEntry element.
If no With option is specified, then the resulting RegistryEntryMetadata element has no Classification, SourceAssociations, TargetAssociations, AuditableEvent, or ExternalData subelements. The set of RegistryEntryMetadata elements, with the StatusResultError list from the RegistryEntryQuery, is returned as the ReturnRegistryEntryResult.
If WithClassifications is specified, then for each E in R do the following: If a ClassificationFilter is not present, then let C be any classification instance linked to E; otherwise, let C be a classification instance linked to E that satisfies the ClassificationFilter (Section REF _Ref509119346 \n \h 8.2.98.2.98.2.98.2.9). For each such C, create a new Classification element as defined in Appendix A..2. Add these Classification elements to their parent RegistryEntryMetadata element.
If WithSourceAssociations is specified, then for each E in R do the following: If an AssociationFilter is not present, then let A be any association instance whose source object is E; otherwise, let A be an association instance that satisfies the AssociationFilter (Section REF _Ref509119346 \n \h 8.2.98.2.98.2.98.2.9) and whose source object is E. For each such A, create a new Association element as defined in Appendix A.2. Add these Association elements as subelements of the WithSourceAssociations and add that element to its parent RegistryEntryMetadata element.
If WithTargetAssociations is specified, then for each E in R do the following: If an AssociationFilter is not present, then let A be any association instance whose target object is E; otherwise, let A be an association instance that satisfies the AssociationFilter (Section REF _Ref509119346 \n \h 8.2.98.2.98.2.98.2.9) and whose target object is E. For each such A, create a new Association element as defined in Appendix A.2. Add these Association elements as subelements of the WithTargetAssociations and add that element to its parent RegistryEntryMetadata element.
If WithAuditableEvents is specified, then for each E in R do the following: If an AuditableEventFilter is not present, then let A be any auditable event instance linked to E; otherwise, let A be any auditable event instance linked to E that satisfies the AuditableEventFilter (Section REF _Ref509119346 \n \h 8.2.98.2.98.2.98.2.9). For each such A, create a new AuditableEvent element as defined in Appendix A.2.A. Add these AuditableEvent elements to their parent RegistryEntryMetadata element.
If WithExternalLinks is specified, then for each E in R do the following: If an ExternalLinkFilter is not present, then let L be any external link instance linked to E; otherwise, let L be any external link instance linked to E that satisfies the ExternalLinkFilter (Section REF _Ref509119346 \n \h 8.2.98.2.98.2.98.2.9). For each such D, create a new ExternalLink element as defined in Appendix A.2.A. Add these ExternalLink elements to their parent RegistryEntryMetadata element.
If any warning or exception error condition results, then add the code and the message to the StatusResult RegistryResponse element that includes that came from the RegistryEntryQueryR result.
Return the set of RegistryEntryMetadata elements and the revised StatusResult as the content of the ReturnRegistryEntryResult.
Examples
A customer of XYZ Corporation has been using a PurchaseOrder DTD registered by XYZ some time ago. Its URN identifier is "urn:com:xyz:po:325". The customer wishes to check on the current status of that DTD, especially if it has been superceded or replaced, and get all of its current classifications. The following query request will return an XML document with the registry entry for the existing DTD as the root, with all of its classifications, and with associations to registry entries for any items that have superceded or replaced it.
id EQUAL "urn:com:xyz:po:325" -- code by Clause, Section REF _Ref509119034 \n \h 8.2.108.2.108.2.108.2.10
-- code by Clause, Section REF _Ref509119034 \n \h 8.2.108.2.108.2.108.2.10
associationType EQUAL "SupercededBy" OR
associationType EQUAL "ReplacedBy"
A client of the Registry registered an XML DTD several years ago and is now thinking of replacing it with a revised version. The identifier for the existing DTD is "urn:xyz:dtd:po97". The proposed revision is not completely upward compatible with the existing DTD. The client desires a list of all registered items that use the existing DTD so they can assess the impact of an incompatible change. The following query returns an XML document that is a list of all RegistryEntry elements that represent registered items that use, contain, or extend the given DTD. The document also links each RegistryEntry element in the list to an element for the identified association.
-- code by Clause, Section REF _Ref509119034 \n \h 8.2.108.2.108.2.108.2.10
associationType EQUAL "Contains" OR
associationType EQUAL "Uses" OR
associationType EQUAL "Extends"
-- code by Clause, Section REF _Ref509119034 \n \h 8.2.108.2.108.2.108.2.10
id EQUAL "urn:xyz:dtd:po97"
-- code by Clause, Section REF _Ref509119034 \n \h 8.2.108.2.108.2.108.2.10
associationType EQUAL "Contains" OR
associationType EQUAL "Uses" OR
associationType EQUAL "Extends"
A user has been browsing the registry and has found a registry entry that describes a package of core-components that should solve the user's problem. The package URN identifier is "urn:com:cc:pkg:ccstuff". Now the user wants to know what's in the package. The following query returns an XML document with a registry entry for each member of the package along with that member's Uses and HasMemberBranch associations.
-- code by Clause, Section REF _Ref509119034 \n \h 8.2.108.2.108.2.108.2.10
associationType EQUAL "HasMember"
-- code by Clause, Section REF _Ref509119034 \n \h 8.2.108.2.108.2.108.2.10
id EQUAL " urn:com:cc:pkg:ccstuff "
-- code by Clause, Section REF _Ref509119034 \n \h 8.2.108.2.108.2.108.2.10
associationType EQUAL "HasMember" OR
associationType EQUAL "Uses"
ReturnRepositoryItem
Purpose
To construct an XML document that contains one or more repository items, and some associated metadata, by submitting a RegistryEntryQuery to the registry/repository that holds the desired objects. NOTE: Initially, the RegistryEntryQuery could be the URN identifier for a single registry entry.
Definition
Semantic Rules
If the RecursiveOption element is not present , then set Limit=0. If the RecursiveOption element is present, interpret its depthLimit attribute as an integer literal. If the depthLimit attribute is not present, then set Limit = -1. A Limit of 0 means that no recursion occurs. A Limit of -1 means that recursion occurs indefinitely. If a depthLimit value is present, but it cannot be interpreted as a positive integer, then stop execution and raise the exception: invalid depth limit; otherwise, set Limit=N, where N is that positive integer. A Limit of N means that exactly N recursive steps will be executed unless the process terminates prior to that limit.
Set Depth=0. Let Result denote the set of RepositoryItem elements to be returned as part of the ReturnRepositoryItemResult. Initially Result is empty. Semantic rules 4 through 10 determine the content of Result.
If the WithDescription element is present, then set WSD="yes"; otherwise, set WSD="no".
Execute the RegistryEntryQuery according to the Semantic Rules specified in Section REF _Ref508520238 \n 8.2.2, and let R be the result set of identifiers for registry entry instances. Let S be the set of status elements returned in the StatusResult. If any status element in S is an exception condition, then stop execution and return the same StatusResult element in the ReturnRepositoryItemResult.
Execute the RegistryEntryQuery according to the Semantic Rules specified in Section REF _Ref508521717 \n 8.2.2, and let R be the result set of identifiers for registry entry instances. Let S be the set of warnings and errors returned. If any element in S is an error condition, then stop execution and return the same set of warnings and errors along with the ReturnRepositoryItemResult.
Execute Semantic Rules 6 and 7 with X as a set of registry references derived from R. After execution of these rules, if Depth is now equal to Limit, then return the content of Result as the set of RepositoryItem elements in the ReturnRepositoryItemResult element; otherwise, continue with Semantic Rule 8.
Let X be a set of RegistryEntry instances. For each registry entry E in X, do the following:
If E.contentURI references a repository item in this registry/repository, then create a new RepositoryItem element, with values for its attributes derived as specified in Semantic Rule REF _Ref508520413 \n 7.
If E.objectType="ClassificationScheme", then put the referenced ClassificationScheme DTD as the subelement of this RepositoryItem. [NOTE: Requires DTD specification!]
If E.objectType="RegistryPackage", then put the referenced RegistryPackage DTD as the subelement of this RepositoryItem. [NOTE: Requires DTD specification!]
Otherwise, i.e., if the object referenced by E has an unknown internal structure, then put the content of the repository item as the #PCDATA of a new ExtrinsicObject subelement of this RepositoryItem.
If E.objectURL references a registered object in some other registry/repository, then create a new RepositoryItem element, with values for its attributes derived as specified in Semantic Rule REF _Ref508520413 \n 7, and create a new ExternalLink element as the subelement of this RepositoryItem.
If E.objectURL is void, i.e. the object it would have referenced has been withdrawn, then create a new RepositoryItem element, with values for its attributes derived as specified in Semantic Rule REF _Ref508520413 \n 7, and create a new WithdrawnObject element as the subelement of this RepositoryItem.
Let E be a registry entry and let RO be the RepositoryItem element created in Semantic Rule REF _Ref508520607 \n 6. Set the attributes of RO to the values derived from the corresponding attributes of E. If WSD="yes", include the value of the description attribute; otherwise, do not include it. Insert this new RepositoryItem element into the Result set.
Let R be defined as in Semantic Rule REF _Ref508520656 \n 3334. Execute Semantic Rule REF _Ref508520675 \n 9 with Y as the set of RegistryEntry instances referenced by R. Then continue with Semantic rule REF _Ref508520706 \n 10.
Let Y be a set of references to RegistryEntry instances. Let NextLevel be an empty set of RegistryEntry instances. For each registry entry E in Y, and for each AssociationType A of the RecursiveAssociationOption, do the following:
Let Z be the set of target items E' linked to E under association instances having E as the source object, E' as the target object, and A as the AssociationType.
Add the elements of Z to NextLevel.
Let X be the set of new registry entries that are in NextLevel but are not yet represented in the Result set.
Case:
If X is empty, then return the content of Result as the set of RepositoryItem elements in the ReturnRepositoryItemResult element.
If X is not empty, then execute Semantic Rules REF _Ref508520607 \n 6 and REF _Ref508520413 \n 7 with X as the input set. When finished, add the elements of X to Y and set Depth=Depth+1. If Depth is now equal to Limit, then return the content of Result as the set of RepositoryItem elements in the ReturnRepositoryItemResult element; otherwise, repeat Semantic Rules REF _Ref508520675 \n 9 and REF _Ref508520706 \n 10 with the new set Y of registry entries.
If any exception, warning, or other status condition results during the execution of the above, then return appropriate RegistryErrorstatus elements in the RegistryResult associated with the as the StatusResult of the ReturnRepositoryItemResult element created in Semantic Rule REF _Ref508520877 \n 5 or Semantic Rule REF _Ref508520706 \n 10.
.
Examples
A registry client has found a registry entry for a core-component item. The item's URN identity is "urn:ebxml:cc:goodthing". But "goodthing" is a composite item that uses many other registered items. The client desires the collection of all items needed for a
complete implementation of "goodthing". The following query returns an XML document that is a collection of all needed items.
-- code by Clause, Section REF _Ref509119034 \n \h 8.2.108.2.108.2.108.2.10
id EQUAL "urn:ebxml:cc:goodthing"
A registry client has found a reference to a core-component routine ("urn:ebxml:cc:rtn:nice87") that implements a given business process. The client knows that all routines have a required association to its defining UML specification. The following query returns both the routine and its UML specification as a collection of two items in a single XML document.
-- code by Clause, Section REF _Ref509119034 \n \h 8.2.108.2.108.2.108.2.10
id EQUAL "urn:ebxml:cc:rtn:nice87"
A user has been told that the 1997 version of the North American Industry Classification System (NAICS) is stored in a registry with URN identifier "urn:nist:cs:naics-1997". The following query would retrieve the complete classification scheme, with all 1810 nodes, as an XML document that validates to a classification scheme DTD.
-- code by Clause, Section REF _Ref509119034 \n \h 8.2.108.2.108.2.108.2.10
id EQUAL "urn:nist:cs:naics-1997"
Note: The ReturnRepositoryItemResult would include a single RepositoryItem that consists of a ClassificationScheme document whose content is determined by the URL HYPERLINK "ftp://xsun.sdct.itl.nist.gov/regrep/scheme/naics.txt" ftp://xsun.sdct.itl.nist.gov/regrep/scheme/naics.txt.
Registry Filters
Purpose
To identify a subset of the set of all persistent instances of a given registry class.
Definition
Semantic Rules
The Clause element is defined in Section REF _Ref509119034 \n \h 8.2.108.2.108.2.108.2.10, Clause.
For every ObjectFilter 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: object attribute error. The ObjectFilter returns a set of identifiers for RegistryObject instances whose attribute values evaluate to True for the Clause predicate.
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.
For every IntrinsicObjectFilter XML element, the leftArgument attribute of any containing SimpleClause shall identify a public attribute of the IntrinsicObject UML class defined in [ebRIM]. If not, raise exception: intrinsic object attribute error. The IntrinsicObjectFilter returns a set of identifiers for IntrinsicObject instances whose attribute values evaluate to True for the Clause predicate.
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.
For every PackageFilter XML element, the leftArgument attribute of any containing SimpleClause shall identify a public attribute of the Package UML class defined in [ebRIM]. If not, raise exception: package attribute error. The PackageFilter returns a set of identifiers for Package instances whose attribute values evaluate to True for the Clause predicate.
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.
For every ContactFilter XML element, the leftArgument attribute of any containing SimpleClause shall identify a public attribute of the Contact or PostalAddress UML class defined in [ebRIM]. If not, raise exception: contact attribute error. The ContactFilter returns a set of identifiers for Contact instances whose attribute values evaluate to True for the Clause predicate.
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. The ClassificationNodeFilter returns a set of identifiers for ClassificationNode instances whose attribute values evaluate to True for the Clause predicate.
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.
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.
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.
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.
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.
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.
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: auditable identity attribute error. The UserFilter returns a set of identifiers for User instances whose attribute values evaluate to True for the Clause predicate.
Example
The following is a complete example of RegistryEntryQuery combined with Clause expansion of RegistryEntryFilter to return a set of RegistryEntry instances whose objectType attibute is CPP and whose status attribute is Approved.
CPP
Approved
XML Clause Constraint Representation
Purpose
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.
Conceptual UML Diagram
The following is a conceptual diagram outlining the Clause base structure. It is expressed in UML for visual depiction.
Figure SEQ Figure \* ARABIC 20: The Clause base structure
Semantic Rules
Predicates and Arguments are combined into a "LeftArgument - Predicate - RightArgument" format to form a Clause. There are two types of Clauses: SimpleClauses and CompoundClauses.
SimpleClauses
A SimpleClause always defines the leftArgument as a text string, sometimes referred to as the Subject of the Clause. SimpleClause itself is incomplete (abstract) and must be extended. SimpleClause is extended to support BooleanClause, StringClause, and RationalClause (abstract).
BooleanClause implicitly defines the predicate as equal to, with the right argument as a boolean. StringClause defines the predicate as an enumerated attribute of appropriate string-compare operations and a right argument as the elements text data. 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
A CompoundClause contains two or more Clauses (Simple or Compound) and a connective predicate. This provides for arbitrarily complex Clauses to be formed.
Definition
Examples
Simple BooleanClause: "Smoker" = True
Simple StringClause: "Smoker" contains "mo"
mo
Simple IntClause: "Age" >= 7
7
Simple FloatClause: "Size" = 4.3
4.3
Compound with two Simples (("Smoker" = False)AND("Age" =< 45))
45
Coumpound with one Simple and one Compound
( ("Smoker" = False)And(("Age" =< 45)Or("American"=True)) )
45
SQL Query Support
The Registry may optionally support an SQL based query capability that is designed for Registry clients that demand more complex query capability. The optional SQLQuery element in the AdhocQueryRequest allows a client to submit complex SQL queries using a declarative query language.
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 (also known as stored procedures) as specified in ISO/IEC 9075-4 [SQL-PSM] and pre-defined routines defined in template form in Appendix REF _Ref509179434 \w \h C.3. The exact syntax of the Registry query language is defined by the BNF grammar in REF _Ref509276097 \w \h C.1.
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.
SQL Query Syntax Binding To [ebRIM]
SQL Queries are defined based upon the query syntax in in Appendix REF _Ref509179371 \w \h C.1 and a fixed relational schema defined in Appendix REF _Ref509179434 \w \h C.3. The relational schema is an algorithmic binding to [ebRIM] as described in the following sections.
Interface and Class Binding
A subset of the Interface and class names defined in [ebRIM] map to table names that may be queried by an SQL query. Appendix REF _Ref509179434 \w \h C.3 defines the names of the ebRIM interfaces and classes that may be queried by an SQL query.
The algorithm used to define the binding of [ebRIM] classes to table definitions in Appendix REF _Ref509179434 \w \h C.3 is as follows:
Only those classes and interfaces that have concrete instances are mapped to relational tables. This results in intermediate interfaces in the inheritance hierarchy, such as RegistryObject and IntrinsicObject, to not map to SQL tables. An exception to this rule is RegistryEntry, which is defined next.
A special view called RegistryEntry is defined to allow SQL queries to be made against RegistryEntry instances. This is the only interface defined in [ebRIM] that does not have concrete instances but is queryable by SQL queries.
The names of relational tables are the same as the corresponding [ebRIM] class or interface name. However, the name binding is case insensitive.
Each [ebRIM] class or interface that maps to a table in Appendix REF _Ref509179434 \w \h C.3 includes column definitions in Appendix REF _Ref509179434 \w \h C.3 where the column definitions are based on a subset of attributes defined for that class or interface in [ebRIM]. The attributes that map to columns include the inherited attributes for the [ebRIM] class or interface. Comments in Appendix REF _Ref509179434 \w \h C.3 indicate which ancestor class or interface contributed which column definitions.
An SQLQuery against a table not defined in Appendix REF _Ref509179434 \w \h C.3 may raise an error condition: result in an ebXMLError message with an InvalidQueryException.
The following sections describe the algorithm for mapping attributes of [ebRIM] to SQLcolumn definitions.
Accessor Method To Attribute Binding
Most of the [ebRIM] interfaces methods are simple get methods that map directly to attributes. For example the getName method on RegistryObject maps to a name attribute of type String. Each get method in [ebRIM] defines the exact attribute name that it maps to in the interface definitions in [ebRIM].
Primitive Attributes Binding
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 interface 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].
Reference Attribute Binding
A few of the [ebRIM] interface methods return references to instances of interfaces or classes defined by [ebRIM]. For example, the getAccessControlPolicy method of the RegistryObject class returns a reference to an instance of an AccessControlPolicy object.
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 REF _Ref509181728 \n \h 8.3.1.38.3.1.38.3.1.38.3.1.3. The data type for the column is UUID as defined in Appendix REF _Ref509179434 \w \h C.3.
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 as defined by [SQL].
Reference attribute binding is a special case of a primitive attribute mapping.
Complex Attribute Binding
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 interface Organization and class Contact.
The SQL query schema algorithmically maps such complex attributes as multiple primitive attributes within the parent table. The mapping simply flattens out the entity class attributes within the parent table. The attribute name for the flattened attributes are composed of a concatenation of attribute names in the refernce chain. For example Organization has a contact attribute of type Contact. Contact has an address attribute of type PostalAddress. PostalAddress has a String attribute named city. This city attribute will be named contact_address_city.
Collection Attribute Binding
A few of the [ebRIM] interface methods return a collection of references to instances of interfaces or classes defined by [ebRIM]. For example, the getPackages method of the ManagedObject class returns a Collection of references to instances of Packages that the object is a member of.
Such collection attributes in [ebRIM] classes have been mapped to stored procedures in Appendix REF _Ref509179434 \w \h C.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.
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.
Semantic Constraints On Query Syntax
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.
Class names and attribute names must be processed in a case insensitive manner.
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].
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.
SQL Query Results
The results of an SQL query is always an ObjectRefList as defined by the AdHocQueryResponse in REF _Ref509063797 \w \h 8.48.48.48.4. This means the result of an SQL query is always a collection of references to instances of a sub-class of the RegistryObject interface in [ebRIM]. This is reflected in a semantic constraint that requires that the SQL select column specified must always be an id column in a table in Appendix REF _Ref509179434 \w \h C.3 for this version of the specification.
Simple Metadata Based Queries
The simplest form of an SQL query is based upon metadata attributes specified for a single class within [ebRIM]. This section gives some examples of simple metadata based queries.
For example, to get the collection of ExtrinsicObjects whose name contains the word Acme and that have a version greater than 1.3, the following query predicates must be supported:
SELECT id FROM ExtrinsicObject WHERE name LIKE %Acme% AND
majorVersion >= 1 AND
(majorVersion >= 2 OR minorVersion > 3);
Note that the query syntax allows for conjugation of simpler predicates into more complex queries as shown in the simple example above.
RegistryEntry Queries
Given the central role played by the RegistryEntry interface in ebRIM, the schema for the SQL query defines a special view called RegistryEntry that allows doing a polymorphic query against all RegistryEntry instances regardless of their actual concrete type or table name.
The following example is the same as Section REF _Ref512854615 \n 8.3.48.3.48.3.48.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.
SELECT id FROM RegistryEntry WHERE name LIKE %Acme% AND
objectType = ExtrinsicObject AND
majorVersion >= 1 AND
(majorVersion >= 2 OR minorVersion > 3);
Classification Queries
This section describes the various classification related queries that must be supported.
Identifying ClassificationNodes
Like all objects in [ebRIM], ClassificationNodes are identified by their ID. However, they may also be identified as 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.
Getting Root Classification Nodes
To get the collection of root ClassificationNodes the following query predicate must be supported:
SELECT cn.id FROM ClassificationNode cn WHERE parent IS NULL
The above query returns all ClassificationNodes that have their parent attribute set to null. Note that the above query may also specify a predicate on the name if a specific root ClassificationNode is desired.
Getting Children of Specified ClassificationNode
To get the children of a ClassificationNode given the ID of that node the following style of query must be supported:
SELECT cn.id FROM ClassificationNode cn WHERE parent =
The above query returns all ClassificationNodes that have the node specified by as their parent attribute.
Getting Objects Classified By a ClassificationNode
To get the collection of ExtrinsicObjects classified by specified ClassificationNodes the following style of query must be supported:
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))
The above query gets 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.
Getting ClassificationNodes That Classify an Object
To get the collection of ClassificationNodes that classify a specified Object the following style of query must be supported:
SELECT id FROM ClassificationNode
WHERE id IN (RegistryEntry_classificationNodes())
Association Queries
This section describes the various Association related queries that must be supported.
Getting All Association With Specified Object As Its Source
To get the collection of Associations that have the specified Object as its source, the following query must be supported:
SELECT id FROM Association WHERE sourceObject =
Getting All Association With Specified Object As Its Target
To get the collection of Associations that have the specified Object as its target, the following query must be supported:
SELECT id FROM Association WHERE targetObject =
Getting Associated Objects Based On Association Attributes
To get the collection of Associations that have specified Association attributes, the following queries must be supported:
Select Associations that have the specified name.
SELECT id FROM Association WHERE name =
Select Associations that have the specified source role name.
SELECT id FROM Association WHERE sourceRole =
Select Associations that have the specified target role name.
SELECT id FROM Association WHERE targetRole =
Select Associations that have the specified association type, where association type is a string containing the corresponding field name described in [ebRIM].
SELECT id FROM Association WHERE
associationType =
Complex Association Queries
The various forms of Association queries may be combined into complex predicates. The following query selects Associations from an object with a specified id, that have the sourceRole buysFrom and targetRole sellsTo:
SELECT id FROM Association WHERE
sourceObject = AND
sourceRole = buysFrom AND
targetRole = sellsTo
Package Queries
To find all Packages that a specified ExtrinsicObject belongs to, the following query is specified:
SELECT id FROM Package WHERE id IN (RegistryEntry_packages())
Complex Package Queries
The following query gets all Packages that a specified object belongs to, that are not deprecated and where name contains "RosettaNet."
SELECT id FROM Package WHERE
id IN (RegistryEntry_packages()) AND
name LIKE %RosettaNet% AND
status <> Deprecated
ExternalLink Queries
To find all ExternalLinks that a specified ExtrinsicObject is linked to, the following query is specified:
SELECT id From ExternalLink WHERE id IN (RegistryEntry_externalLinks())
To find all ExtrinsicObjects that are linked by a specified ExternalLink, the following query is specified:
SELECT id From ExtrinsicObject WHERE id IN (RegistryEntry_linkedObjects())
Complex ExternalLink Queries
The following query gets all ExternalLinks that a specified ExtrinsicObject belongs to, that contain the word legal in their description and have a URL for their externalURI.
SELECT id FROM ExternalLink WHERE
id IN (RegistryEntry_externalLinks()) AND
description LIKE %legal% AND
externalURI LIKE %http://%
Audit Trail Queries
To get the complete collection of AuditableEvent objects for a specified ManagedObject, the following query is specified:
SELECT id FROM AuditableEvent WHERE registryEntry =
Ad Hoc Query Request/Response
A client submits an ad hoc query to the ObjectQueryManager by sending an AdhocQueryRequest. The AdhocQueryRequest contains a sub-element that defrines a query in one of the supported Registry query mechanisms.
The ObjectQueryManager sends an AdhocQueryResponse either synchronously or asynchronously back to the client. The AdhocQueryResponse returns a collection of objects whose element type is in the set of element types represented by the leaf nodes of the RegistryEntry hierarchy in [ebRIM].
Figure SEQ Figure \* ARABIC 2121211819: Submit Ad Hoc Query Sequence Diagram
Figure SEQ Figure \* ARABIC 20: Submit Ad Hoc Query Asynchronous Sequence Diagram
For details on the schema for the business documents shown in this process refer to REF _Ref514031776 \r \h Appendix AAppendix REF _Ref503775452 \w \h A.2.
Content Retrieval
A client retrieves content via the Registry by sending the GetContentRequest to the ObjectQueryManager. The GetContentRequest specifies a list of Object references for Objects that need to be retrieved. The ObjectQueryManager returns the specified content by sending a GetContentResponse message to the ObjectQueryManagerClient interface of the client. If there are no errors encountered, the GetContentResponse message includes the specified content as additional payloads within the message. In addition to the GetContentResponse payload, there is one additional payload for each content that was requested. If there are errors encountered, the RegistryGetContentResponse payload includes an ebXMLError error and there are no additional content specific payloads.
Identification Of Content Payloads
Since the GetContentResponse message may include several repository items as additional payloads, it is necessary to have a way to identify each payload in the message. To facilitate this identification, the Registry must do the following:
Use the ID for each RegistryEntry instance that describes the repository item as the DocumentLabel element in the DocumentReference for that object in the Manifest element of the ebXMLHeader.
GetContentResponse Message Structure
The following message fragment illustrates the structure of the GetContentResponse Message that is returning a Collection of CPPs as a result of a GetContentRequest that specified the IDs for the requested objects. Note that the ID for each object retrieved in the message as additional payloads is used as its DocumentLabel in the Manifest of the ebXMLHeader.
--PartBoundary
ObjectManagersubmitObjectsXML instances that are parameters for the particular Registry Interface / Method. These are RIM structures that dont include repository items, just a reference contentURI to them.XML instance of CPP 1. This is a repository item.XML instance of CPP 2. This is a repository item.
--PartBoundary
Content-ID: registryentries@example.com
Content-Type: text/xml
--PartBoundary
Content-ID: cpp1@example.com
Content-Type: text/xml
--PartBoundary
Content-ID: cpp2@example.com
Content-Type: text/xml
--PartBoundary--
--7250537.978150567601.JavaMail.najmi.irian
GetContentsResponse6835fb:e3be512ac8:-8000 ID for CPP content #1 .... ID for CPP content #2
--7250537.978150567601.JavaMail.najmi.irian
Content-Type: application/xml
Content-Description: GetContentsResponse
Content-ID: 6835fb:e3be512ac8:-7ffc
Content-Length: 97
--7250537.978150567601.JavaMail.najmi.irian
Content-Type: application/xml
Content-Description: ID for CPP content #1
Content-ID: .
--7250537.978150567601.JavaMail.najmi.irian
Content-Type: application/xml
Content-Description: ID for CPP content #2
Content-ID: .
--7250537.978150567601.JavaMail.najmi.irian--
Query And Retrieval: Typical Sequence
The following diagram illustrates the use of both browse/drilldown and ad hoc queries followed by a retrieval of content that was selected by the queries.
Figure SEQ Figure \* ARABIC 2323232021: Typical Query and Retrieval Sequence
Registry Security
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].
In the current version of this specification, a minimalist approach has been specified for Registry security. The philosophy is that Any known entity can publish content and anyone can view published content. The Registry information model has been designed to allow more sophisticated security policies in future versions of this specification.
Integrity of Registry Content
It is assumed that most business registries do not have the resources to validate the veracity of the content submitted to them. The minimal integrity that the Registry must provide is to ensure that content submitted by a Submitting Organization (SO) is maintained in the Registry without any tampering either en-route or within the Registry. Furthermore, the Registry must make it possible to identify the SO for any Registry content unambiguously.
Message Payload Signature
Integrity of Registry content requires that all submitted content must be signed by the Registry client as defined by [SEC]. The signature on the submitted content ensures that:
The content has not been tampered with en-route or within the Registry.
The contents veracity can be ascertained by its association with a specific submitting organization
Authentication
The Registry must be able to authenticate the identity of the Principal associated with client requests. Authentication is required to identify the ownership of content as well as to identify what privileges a Principal can be assigned with respect to the specific objects in the Registry.
The Registry must perform Authentication on a per request 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.
The Registry must implement a credential-based authentication mechanism based on digital certificates and signatures. The Registry uses the certificate DN from the signature to authenticate the user.
Message Header Signature
Message headers may be signed by the sending ebXML Messaging Service as defined by [SEC]. Since this specification is not yet finalized, this version does not require that the message header be signed. In the absence of a message header signature, the payload signature is used to authenticate the identity of the requesting client.
Confidentiality
On-the-wire Message Confidentiality
It is suggested but not required that message payloads exchanged between clients and the Registry be encrypted during transmission. Payload encryption must abide by any restrictions set forth in [SEC].
Confidentiality of Registry Content
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. Therefore, the Registry must be able to decrypt any submitted content after it has been received and prior to storing it in its repository. This implies that the Registry and the client have an a priori agreement regarding encryption algorithm, key exchange agreements, etc. This service is not addressed in this specification.
Authorization
The Registry must provide an authorization mechanism based on the information model defined in [ebRIM]. In this version of the specification the authorization mechanism is based on a default Access Control Policy defined for a pre-defined set of roles for Registry users. Future versions of this specification will allow for custom Access Control Policies to be defined by the Submitting Organization.
Pre-defined Roles For Registry Users
The following roles must be pre-defined in the Registry:
RoleDescriptionContentOwnerThe submitter or owner of a Registry content. Submitting Organization (SO) in ISO 11179RegistryAdministratorA super user that is an administrator of the Registry. Registration Authority (RA) in ISO 11179RegistryGuestAny unauthenticated user of the Registry. Clients that browse the Registry do not need to be authenticated.Default Access Control Policies
The Registry must create a default AccessControlPolicy object that grants the default permissions to Registry users based upon their assigned role.
The following table defines the Permissions granted by the Registry to the various pre-defined roles for Registry users based upon the default AccessControlPolicy.
RolePermissionsContentOwnerAccess to all methods on Registry Objects that are owned by the ContentOwner.
RegistryAdministratorAccess to all methods on all Registry ObjectsRegistryGuestAccess to all read-only (getXXX) methods on all Registry Objects (read-only access to all content).
The following list summarizes the default role-based AccessControlPolicy:
The Registry must implement the default AccessControlPolicy and associate it with all Objects in the Registry
Anyone can publish content, but needs to be authenticated
Anyone can access the content without requiring authentication
The ContentOwner has access to all methods for Registry Objects owned by them
The RegistryAdministrator has access to all methods on all Registry Objects
Unauthenticated clients can access all read-only (getXXX) methods
At the time of content submission, the Registry must assign the default ContentOwner role to the Submitting Organization (SO) as authenticated by the credentials in the submission message. In the current version of this specification, it will be the DN as identified by the certificate
Clients that browse the Registry need not use certificates. The Registry must assign the default RegistryGuest role to such clients.
ebXML Registry Schemas and DTD Definitions
The following is the are ddefinitions for the various ebXML Message payloads described in this document.
ebXML Error Message
The following error syntax is copied from the ebXML Message Services Specification, version 0.99, lines 2364 to 2389:
ebXML Registry DTD
%errorSchema;
Interpretation of UML Diagrams
This section describes in abstract terms the conventions used to define ebXML business process description in UML.
UML Class Diagram
A UML class diagram is used to describe the Service Interfaces (as defined by [ebCPP]) required to implement an ebXML Registry Services and clients. See REF _Ref502258862 \h Figure 2Figure 2Figure 2Figure 2Figure 3 on page PAGEREF _Ref502303319 \h 14 for an example. The UML class diagram contains:
A collection of UML interfaces where each interface represents a Service Interface for a Registry service.
Tabular description of methods on each interface where each method represents an Action (as defined by [ebCPP]) within the Service Interface representing the UML interface.
Each method within a UML interface specifies one or more parameters, where the type of each method argument 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.
UML Sequence Diagram
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, request to response association as well as request to error response association as described by [ebCPP].
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 arrow-head for the link. A half arrow-head represents asynchronous communication. A full arrow-head 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 REF _Ref502464956 \h on page PAGEREF _Ref502464988 \h 202021 for an example.
SQL Query
SQL Query Syntax Specification
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 , modulo the restrictions identified below:
A