Committee Specification Draft 02 /
Public Review Draft 01

12 May 2011

Specification URIs:

This version:

http://docs.oasis-open.org/regrep/regrep-core/v4.0/csprd01/regrep-core-rim-v4.0-csprd01.odt (Authoritative)
http://docs.oasis-open.org/regrep/regrep-core/v4.0/csprd01/regrep-core-rim-v4.0-csprd01.pdf
http://docs.oasis-open.org/regrep/regrep-core/v4.0/csprd01/regrep-core-rim-v4.0-csprd01.html

Previous version:

http://docs.oasis-open.org/regrep/regrep-core/v4.0/csd01/regrep-core-rim-v4.0-csd01.odt (Authoritative)
http://docs.oasis-open.org/regrep/regrep-core/v4.0/csd01/regrep-core-rim-v4.0-csd01.pdf
http://docs.oasis-open.org/regrep/regrep-core/v4.0/csd01/regrep-core-rim-v4.0-csd01.html

Latest version:

http://docs.oasis-open.org/regrep/regrep-core/v4.0/regrep-core-rim-v4.0.odt (Authoritative)
http://docs.oasis-open.org/regrep/regrep-core/v4.0/regrep-core-rim-v4.0.pdf

http://docs.oasis-open.org/regrep/regrep-core/v4.0/regrep-core-rim-v4.0.html

Technical Committee:

OASIS ebXML Registry TC

Chairs:

Kathryn Breininger, Boeing

Farrukh Najmi, Wellfleet Software

Editors:

Farrukh Najmi, Wellfleet Software

Nikola Stojanovic, Individual

Related work:

This specification replaces or supersedes the OASIS ebXML RegRep 3.0 specifications.

This specification consists of the following documents, schemas, and ontologies:

●  Part 0: Overview Document - provides a global overview and description of all the other parts

●  Part 1: Registry Information Model (ebRIM) (this document) - specifies the types of metadata and content that can be stored in an ebXML RegRep

●  Part 2: Services and Protocols (ebRS) - specifies the services and protocols for ebXML RegRep

●  Part 3: XML Schema - specifies the XML Schema for ebXML RegRep

●  Part 4: WSDL - specifies the WSDL interface descriptions for ebXML RegRep

●  Part 5: XML Definitions - specifies the canonical XML data for ebXML RegRep as well as example XML documents used in the specification

Declared XML namespaces:

See Part 0: Overview Document

Abstract:

This document defines the types of metadata and content that can be stored in an ebXML RegRep.

A separate document, OASIS ebXML RegRep Version 4.0 Part 2: Services and Protocols (ebRS), defines the services and protocols for an ebXML RegRep.

Status:

This document was last revised or approved by the OASIS ebXML Registry TC on the above date. The level of approval is also listed above. Check the "Latest Version" location noted above for possible later revisions of this document.

Technical Committee members should send comments on this specification to the Technical Committee's email list. Others should send comments to the Technical Committee by using the "Send A Comment" button on the Technical Committee's web page at http://www.oasis-open.org/committees/regrep/.

For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Technical Committee web page (http://www.oasis-open.org/committees/regrep/ipr.php).

Citation format:

When referencing this specification the following citation format should be used:

[regrep-rim-v4.0]

OASIS ebXML RegRep Version 4.0 Part 1: Registry Information Model (ebRIM).  12 May 2011.  OASIS Committee Specification Draft 02 / Public Review Draft 01. http://docs.oasis-open.org/regrep/regrep-core/v4.0/csprd01/regrep-core-rim-v4.0-csprd01.odt.

Copyright © OASIS Open 2010-2011. All Rights Reserved.

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.

OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.

The name "OASIS" is a trademark of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see http://www.oasis-open.org/who/trademark.php for above guidance.

Table of Contents

1 Introduction..................................................................................................................................... 9

1.1 Terminology.............................................................................................................................. 9

1.2 XML Schema............................................................................................................................ 9

1.3 Information Model Types: Inheritance View................................................................................. 9

1.4 Extending ebRIM..................................................................................................................... 10

1.5 Canonical ClassificationSchemes............................................................................................. 11

1.6 Document Organization............................................................................................................ 11

2 Core Information Model.................................................................................................................. 13

2.1 InternationalStringType............................................................................................................. 13

2.1.1 Syntax............................................................................................................................. 13

2.1.2 Example.......................................................................................................................... 14

2.1.3 Description...................................................................................................................... 14

2.2 LocalizedStringType................................................................................................................ 14

2.2.1 Syntax............................................................................................................................. 14

2.2.2 Example.......................................................................................................................... 14

2.2.3 Description...................................................................................................................... 14

2.3 ExtensibleObjectType.............................................................................................................. 15

2.3.1 Syntax............................................................................................................................. 15

2.3.2 Example.......................................................................................................................... 15

2.3.3 Description...................................................................................................................... 15

2.4 SlotType................................................................................................................................. 15

2.4.1 Syntax............................................................................................................................. 16

2.4.2 Example.......................................................................................................................... 16

2.4.3 Description...................................................................................................................... 16

2.5 ValueType............................................................................................................................... 16

2.5.1 Syntax............................................................................................................................. 16

2.5.2 Description...................................................................................................................... 17

2.6 IdentifiableObjectType............................................................................................................. 17

2.6.1 Syntax............................................................................................................................. 18

2.6.2 Example.......................................................................................................................... 18

2.6.3 Description...................................................................................................................... 18

2.7 RegistryObjectType................................................................................................................. 18

2.7.1 Syntax............................................................................................................................. 18

2.7.2 Description...................................................................................................................... 19

2.8 VersionInfoType...................................................................................................................... 21

2.8.1 Syntax............................................................................................................................. 21

2.8.2 Example.......................................................................................................................... 21

2.8.3 Description...................................................................................................................... 21

2.9 objectReferenceType............................................................................................................... 21

2.9.1 Syntax............................................................................................................................. 22

2.9.2 Example.......................................................................................................................... 22

2.9.3 Description...................................................................................................................... 22

2.10 ObjectRefType...................................................................................................................... 24

2.10.1 Syntax........................................................................................................................... 24

2.10.2 Description..................................................................................................................... 24

2.11   DynamicObjectRefType........................................................................................................ 24

2.11.1 Syntax............................................................................................................................ 24

2.11.2 Description..................................................................................................................... 25

2.12 ExtrinsicObjectType............................................................................................................... 25

2.12.1 Syntax........................................................................................................................... 25

2.12.2 Example......................................................................................................................... 25

2.12.3 Description..................................................................................................................... 26

2.13 CommentType....................................................................................................................... 26

2.13.1 Syntax........................................................................................................................... 26

2.13.2 Example......................................................................................................................... 27

2.13.3 Description..................................................................................................................... 27

2.14 RegistryPackageType............................................................................................................ 27

2.14.1 Syntax........................................................................................................................... 27

2.14.2 Example......................................................................................................................... 28

2.14.3 Description..................................................................................................................... 28

2.15 ExternalIdentifierType............................................................................................................. 29

2.15.1 Syntax........................................................................................................................... 29

2.15.2 Example......................................................................................................................... 29

2.15.3 Description..................................................................................................................... 29

2.16 ExternalLinkType................................................................................................................... 30

2.16.1 Syntax........................................................................................................................... 30

2.16.2 Example......................................................................................................................... 30

2.16.3 Description..................................................................................................................... 30

3 Association Information Model........................................................................................................ 32

3.1 Source and Target Objects....................................................................................................... 32

3.2 Type of an Association............................................................................................................ 32

3.3 AssociationType...................................................................................................................... 32

3.3.1 Syntax............................................................................................................................. 32

3.3.2 Example.......................................................................................................................... 33

3.3.3 Description...................................................................................................................... 33

3.4 Access Control........................................................................................................................ 33

4 Classification Information Model..................................................................................................... 34

4.1 TaxonomyElementType............................................................................................................ 36

4.1.1 Syntax............................................................................................................................. 36

4.1.2 Description...................................................................................................................... 36

4.2 ClassificationSchemeType....................................................................................................... 37

4.2.1 Syntax............................................................................................................................. 37

4.2.2 Example.......................................................................................................................... 37

4.2.3 Description...................................................................................................................... 37

4.3 ClassificationNodeType........................................................................................................... 38

4.3.1 Syntax............................................................................................................................. 38

4.3.2 Description...................................................................................................................... 38

4.3.3  Canonical Path Syntax..................................................................................................... 39

4.4  ClassificationType.................................................................................................................. 39

4.4.1 Syntax............................................................................................................................. 39

4.4.2 Example.......................................................................................................................... 40

4.4.3 Description...................................................................................................................... 40

5 Provenance Information Model....................................................................................................... 42

5.1 PostalAddressType................................................................................................................. 42

5.1.1 Syntax............................................................................................................................. 42

5.1.2 Example.......................................................................................................................... 43

5.1.3 Description...................................................................................................................... 43

5.2 TelephoneNumberType............................................................................................................. 43

5.2.1 Syntax............................................................................................................................. 43

5.2.2 Example.......................................................................................................................... 44

5.2.3 Description...................................................................................................................... 44

5.3 EmailAddressType.................................................................................................................. 44

5.3.1 Syntax............................................................................................................................. 44

5.3.2 Example.......................................................................................................................... 45

5.3.3 Description...................................................................................................................... 45

5.4 PartyType............................................................................................................................... 45

5.4.1 Syntax............................................................................................................................. 45

5.4.2 Description...................................................................................................................... 46

5.5 PersonType............................................................................................................................. 46

5.5.1 Syntax............................................................................................................................. 46

5.5.2 Example.......................................................................................................................... 46

5.5.3 Description...................................................................................................................... 46

5.6 PersonNameType.................................................................................................................... 47

5.6.1 Syntax............................................................................................................................. 47

5.6.2 Example.......................................................................................................................... 47

5.6.3 Description...................................................................................................................... 47

5.7 OrganizationType..................................................................................................................... 47

5.7.1 Syntax............................................................................................................................. 48

5.7.2 Example.......................................................................................................................... 48

5.7.3 Description...................................................................................................................... 48

5.8 Associating Organization With Persons..................................................................................... 48

5.9 Associating Organization With Organizations............................................................................. 49

5.10 Associating Organizations With RegistryObjects...................................................................... 49

6 Service Information Model.............................................................................................................. 50

6.1 ServiceType............................................................................................................................ 50

6.1.1 Syntax............................................................................................................................. 50

6.1.2 Example.......................................................................................................................... 50

6.1.3 Description...................................................................................................................... 51

6.2 ServiceEndpointType............................................................................................................... 51

6.2.1 Syntax............................................................................................................................. 51

6.2.2 Example.......................................................................................................................... 51

6.2.3 Description...................................................................................................................... 51

6.3 ServiceBindingType................................................................................................................. 52

6.3.1 Syntax............................................................................................................................. 52

6.3.2 Example.......................................................................................................................... 52

6.3.3 Description...................................................................................................................... 52

6.4 ServiceInterfaceType............................................................................................................... 52

6.4.1 Syntax............................................................................................................................. 52

6.4.2 Example.......................................................................................................................... 53

6.4.3 Description...................................................................................................................... 53

7 Query Information Model................................................................................................................ 54

7.1 QueryDefinitionType................................................................................................................ 54

7.1.1 Syntax............................................................................................................................. 54

7.1.2 Example.......................................................................................................................... 55

7.1.3 Description...................................................................................................................... 55

7.2 ParameterType........................................................................................................................ 55

7.2.1 Syntax............................................................................................................................. 55

7.2.2 Example.......................................................................................................................... 56

7.2.3 Description...................................................................................................................... 56

7.3 QueryExpressionType.............................................................................................................. 57

7.3.1 Syntax............................................................................................................................. 57

7.3.2 Description...................................................................................................................... 57

7.4 StringQueryExpressionType..................................................................................................... 57

7.4.1 Syntax............................................................................................................................. 58

7.4.2 Example.......................................................................................................................... 58

7.4.3 Description...................................................................................................................... 58

7.5 XMLQueryExpressionType....................................................................................................... 58

7.5.1 Syntax............................................................................................................................. 58

7.5.2 Example.......................................................................................................................... 59

7.5.3 Description...................................................................................................................... 59

7.6 QueryType.............................................................................................................................. 59

7.6.1 Syntax............................................................................................................................. 59

7.6.2 Example.......................................................................................................................... 59

7.6.3 Description...................................................................................................................... 59

8 Event Information Model................................................................................................................ 61

8.1 AuditableEventType................................................................................................................. 61

8.1.1 Syntax............................................................................................................................. 62

8.1.2 Example.......................................................................................................................... 62

8.1.3 Description...................................................................................................................... 62

8.2 ActionType.............................................................................................................................. 63

8.2.1 Syntax............................................................................................................................. 63

8.2.2 Description...................................................................................................................... 63

8.3 SubscriptionType.................................................................................................................... 64

8.3.1 Syntax............................................................................................................................. 64

8.3.2 Example.......................................................................................................................... 64

8.3.3 Description...................................................................................................................... 64

8.4 DeliveryInfoType..................................................................................................................... 65

8.4.1 Syntax............................................................................................................................. 65

8.4.2 Description...................................................................................................................... 66

8.5 NotificationType...................................................................................................................... 67

8.5.1 Syntax............................................................................................................................. 67

8.5.2 Example.......................................................................................................................... 67

8.5.3 Description...................................................................................................................... 67

9 Federation Information Model......................................................................................................... 69

9.1 Federation Configuration......................................................................................................... 69

9.2 RegistryType........................................................................................................................... 69

9.2.1 Syntax............................................................................................................................. 70

9.2.2 Example.......................................................................................................................... 70

9.2.3 Description...................................................................................................................... 70

9.3 FederationType....................................................................................................................... 71

9.3.1 Syntax............................................................................................................................. 71

9.3.2 Example.......................................................................................................................... 71

9.3.3 Description...................................................................................................................... 72

10 Access Control Information Model................................................................................................. 73

10.1 Defining an Access Control Policy.......................................................................................... 74

10.2 Assigning Access Control Policy to a RegistryObject.............................................................. 74

10.2.1 Default Access Control Policy for a RegistryObject.......................................................... 74

10.2.2 Access Control Policy Inheritance.................................................................................... 75

10.2.3 Performance Implications................................................................................................ 75

10.3 Defining a Contextual Role..................................................................................................... 75

10.3.1 RoleType........................................................................................................................ 76

10.3.2 Example......................................................................................................................... 76

10.3.3 Description..................................................................................................................... 76

10.4 Assigning a Contextual Role to a Subject................................................................................ 76

10.5 Action Matching..................................................................................................................... 77

10.5.1 Action Attribute: reference-source.................................................................................... 78

10.5.2 Action Attribute: reference-source-attribute....................................................................... 78

10.6 Subject Matching................................................................................................................... 78

10.6.1 Matching Subjects By Id................................................................................................. 79

10.6.2 Matching Subject By Role............................................................................................... 79

10.7 Resource Matching................................................................................................................ 80

10.7.1 Matching a Resource By Id.............................................................................................. 81

10.7.2 Matching a Resource Using XPATH Expression................................................................ 81

10.8 Canonical XACML Functions.................................................................................................. 82

10.8.1 Function AssociationExists............................................................................................. 82

10.8.2 Function ClassificationNodeCompare.............................................................................. 82

10.8.3 Function matches-role..................................................................................................... 83

10.9 Constraints on XACML Binding.............................................................................................. 84

10.10 Resolving Policy References................................................................................................ 84

 

Illustration Index

Illustration 1: Information Model Inheritance View................................................................................ 10

Illustration 2: Core Information Model................................................................................................. 13

Illustration 3: Association Example..................................................................................................... 32

Illustration 4: Classification Example.................................................................................................. 35

Illustration 5: Classification Information Model.................................................................................... 36

Illustration 6: Provenance Information Model...................................................................................... 42

Illustration 7: Service Information Model............................................................................................. 50

Illustration 8: Query Information Model............................................................................................... 54

Illustration 9: Event Information Model............................................................................................... 61

Illustration 10: Federation Information Model...................................................................................... 69

Illustration 11: Assigning Access Control Policy to a RegistryObject.................................................... 74

 

Index of Tables

All text is normative unless otherwise indicated.

This document specifies the ebXML RegRep registry information model. For a general overview of ebXML RegRep and other related parts of the specification please refer to Part 0 [regrep-overview-v4.0].

1.1   Terminology

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in IETF [RFC 2119].

1.2   XML Schema

The ebXML Registry Information Model is defined as an XML Schema in the file “/xsd/rim.xsd” in the specification distribution zip file. It defines the metadata types and their relationships within ebXML RegRep specifications.

1.3   Information Model Types: Inheritance View

The central type in the model is the RegistryObjectType. An instance of  RegistryObjectType represents an ebRIM metadata object.

Illustration 1 shows the inheritance or “Is-A” relationships between the various types derived from RegistryObjectType in the information model. Note that it does not show the other types of relationships, such as “Has-A” relationships, as they will be presented in subsequent diagrams. The attributes and elements of each type are also not shown to conserve page space. Detailed description of attributes and elements of each type will be displayed in tabular form within the detailed description of each type.

 

1.4   Extending ebRIM

The XML Schema for ebRIM uses XML Schema type substitution feature to allow use of schema type extensions.

A deployment or profile specification of ebXML RegRep MAY define new types that extend the types defined in this specification as long as the XML Schema for ebRIM supports such extension.

A server MAY support the schema type extensibility feature. The following requirements are defined for a server that supports the schema type extensibility feature:

●  The server protocols as defined by [regrep-rs-v4.0] MUST support extended types in a manner equivalent to pre-defined types. Specifically they MUST support submit, update, versioning and removal of extended types derived directly or indirectly from RegistryObjectType

●  The server MUST be able to faithfully persist instances of extended types including all extension attributes and elements without any information loss

●  The server MUST be able to faithfully return instances of extension types including extension attributes and elements within a query response without any information loss

●  This specification does not prescribe how a server may support the addition of new extension types to the server

1.5   Canonical ClassificationSchemes

ClassificationSchemes are defined in detail in the Classification Information Model. They are used by the specification for a wide variety of purposes within the ebXML RegRep specifications.

This specification uses several standard ClassificationSchemes referred to as canonical  ClassificationSchemes. The values defined within canonical ClassificationSchemes are defined using standard ClassificationNodes that are referred to as canonical ClassificationNodes.

The directory “/xml/minDB” within the specification distribution zip file contains the canonical ClassificationSchemes defined by the ebXML RegRep specifications. The canonical ClassificationSchemes and ClassificationNodes are typically described using the rim:Description element within these files.

These canonical ClassificationSchemes MUST be present in all conforming ebXML RegRep servers. These Canonical ClassificationSchemes MAY be extended by adding additional ClassificationNodes. However, a ClassificationNode defined normatively in the canonical ClassificationScheme definitions MUST NOT be modified within a registry. In particular they MUST preserve their canonical id attributes in all servers.

1.6   Document Organization

The types in the information model are presented in related groups as follows:

●  Core Information Model: Defines core metadata types in the model including the abstract base types

●  Association Information Model: Defines types that enable objects to be associated with each other

●  Classification Information Model: Defines types that enable objects to be classified

●  Provenance Information Model: Defines types that enable the description of provenance or source information about an object

●  Service Information Model: Defines types that enable service description

●  Query Information Model: Defines types that enable definition and invocation of queries

●  Event Information Model: Defines types that enable the event subscription and notification feature defined in [regrep-rs-v4.0]

●  Federation Information Model: Defines types that enable the federated registries feature defined in [regrep-rs-v4.0]

●  Access Control Information Model: Defines types that enable access control and authorization for ebXML RegRep

The remainder of this document will describe each of the above related group of information model types in a dedicated chapter named accordingly.

The core information model is centered around the RegistryObjectType type as shown in figure below. Each type will be defined in detail in subsequent section.

2.1   InternationalStringType

The InternationalStringType type is used throughout the schema whenever a textual value needs to be represented in one or more local languages.

The InternationalStringType has a sequence of LocalizedString instances, where each LocalizedString instance is specific to a particular locale.

2.1.1   Syntax

2.1.2   Example

2.1.3   Description

Node	Type	Cardinality	Default Value	Specified By	Mutable
LocalizedString	LocalizedStringType	0..*		Client	Yes

 

●  Element LocalizedString - An InternationalStringType instance MAY have zero or more LocalizedString elements where each defines a string value within a specific local language

2.2   LocalizedStringType

This type allows the definition of a string value using the specified local language. It is used within the InternationalStringType as the type of the LocalizedString sub-element. Note that the character set for all LocalizedStringType instances in an XML document is defined by the charset attribute within the Content-Type mime header for the XML document as shown in example below:

 

   Content-Type: text/xml; charset="UTF-8"

 

2.2.1   Syntax

2.2.2   Example

2.2.3   Description

Node	Type	Cardinality	Default Value	Specified By	Mutable
xml:lang	xs:language	0..1	en-US	Client	Yes
value	rim:FreeFormText	1		Client	Yes

 

●  Attribute xml:lang - Each LocalizedStringType instance MAY have a xml:lang attribute that specifies the language used by that LocalizedStringType instance. The xml:lang attribute and legal values for it are defined by [XML].

●  Attribute value - Each LocalizedStringType instance MUST have a value attribute that specifies the string value used by that LocalizedStringType instance

2.3   ExtensibleObjectType

This type is the root type for most other types in rim.xsd. It allows extension properties called slots to be added to instances of this type using Slot sub-elements.

2.3.1   Syntax

2.3.2   Example

The following example shows how an OrganizationType instance which is of type ExtensibleObjectType MAY use Slot sub-elements to define a tax payer id for the organization.

 

2.3.3   Description

Node	Type	Cardinality	Default Value	Specified By	Mutable
Slot	SlotType	0..*		Client	Yes

 

●  Element Slot – Allows an extension property to be added to any ExtensibleObjectType instance

2.4   SlotType

Base Type: ExtensibleObjectType

The SlotType represents an extensible property for a RegistryObjectType instance . It can contain any type of information that may be represented in an XML document. It is an important extensibility mechanism with ebRIM.

A SlotType instance has a name and a value. The value is of type ValueType. ValueType is abstract and has several concrete sub-types defined within this specification.

Note that SlotType extends  ExtensibleObjectType which means that a SlotType element may itself have SlotType sub-elements.

2.4.1   Syntax

2.4.2   Example

The following example shows how a GML geometry value may be specified as a Slot.

2.4.3   Description

Node	Type	Cardinality	Default Value	Specified By	Mutable
name	LongText	1		Client	Yes
SlotValue	ValueType	0..1		Client	Yes
type	LongText	0..1		Client	Yes

 

●  Attribute name – The name of this SlotType instance. The name of the slot MUST be unique within the universe of slot names for all sibling slots within its parent object

●  Element SlotValue – This element is the container for the actual value for the SlotType instance

●  Attribute type – A string that specifies the type for the SlotType instance. The type may be used to assign a category for the  SlotType instance

2.5   ValueType

This type is abstract base type for the value of a SlotType instance.

2.5.1   Syntax

2.5.2   Description

The ValueType is an abstract base type that does not define any attributes or elements. This specification defines several concrete sub-types that extend ValueType

●  AnyValueType – This concrete sub-type of ValueType is used as a container for any well-formed XML element value in any namespace

●  BooleanValueType - This concrete sub-type of ValueType is used as a container for a boolean value

●  CollectionValueType - This concrete sub-type of ValueType is used as a container for a collection of values. It may be used to represent a SlotValue that is a collection of values where each value is represented by a ValueType instance

○  Attribute collectionType – Defines the type of collection for the CollectionValueType. Must be an objectReferenceType that references a ClassificationNode in the canonical ClassificationScheme CollectionTypeScheme. A server MUST enforce the following semantics associated with the following canonical collection types:

■   List – Server MUST maintain the order of the values in the collection

■   Set – Server MUST NOT allow duplicate values in the collection

■   Sorted Set – Server  MUST NOT allow duplicate values in the collection and MUST maintain a sort order according to the alphanumeric ordering of its elements according to the default locale associated with the server

■   Bag – Server MUST allow duplicate values and MAY not maintain order of values

●  DateTimeValueType - This concrete sub-type of ValueType is used as a container for a dateTime value

●  DurationValueType - This concrete sub-type of ValueType is used as a container for a duration value

●  FloatValueType - This concrete sub-type of ValueType is used as a container for a float value

●  IntegerValueType - This concrete sub-type of ValueType is used as a container for an integer value

●  InternationalStringValueType - This concrete sub-type of ValueType is used as a container for an InternationalSringType value capable of holding strings in multiple locales

●  MapValueType - This concrete sub-type of ValueType is used as a container for a map value. A map consists of Entry sub-elements where each Entry consists of an EntryKey and EntryValue both of which are of type ValueType

●  SlotValueType – This concrete sub-type of ValueType is used as a container for a SlotType value

●  StringValueType – This concrete sub-type of ValueType is used as a container for a string value

●  VocabularyTermValueType - This concrete sub-type of ValueType  is used as a container for a VocabularyTermType value. It is used to reference a term in some externally defined coded vocabulary (e.g. Dublin Core)

2.6   IdentifiableObjectType

Base Type: ExtensibleObjectType

This type extends ExtensibleObjectType and allows its instances to be uniquely identifiable by a unique id.

2.6.1   Syntax

2.6.2   Example

2.6.3   Description

Node	Type	Cardinality	Default Value	Specified By	Mutable
id	xs:string	1		Client	Yes

 

●  Attribute id – Specifies the unique identifier for an IdentifiableType instance.

2.7   RegistryObjectType

Base Type: IdentifiableType

This type extends IdentifiableObjectType and is the common base type for all queryable metadata elements in ebRIM.

2.7.1   Syntax

2.7.2   Description

Node	Type	Cardinality	Default Value	Specified By	Mutable
Classification	ClassificationType	0..*		Client	Yes
Description	InternationalStringType	0..1		Client	Yes
ExternalIdentifer	ExternalIdentifierType	0..*		Client	Yes
ExternalLink	ExternalLinkType	0..*		Client	Yes
lid	string	0..1		Client or Server	No
Name	InternationalStringType	0..1		Client	Yes
objectType	objectReferenceType	0..1		Client or Server	No
owner	string	0..1		Server	Yes
status	objectReferenceType	0..1		Server	Yes
VersionInfo	VersionInfoType	0..1		Server	No

 

●  Element Classification - A RegistryObjectType instance MAY have zero or more ClassificationType instances that are composed within the RegistryObject. A ClassificationType instance classify the RegistryObject using a value within a ClassificationScheme

●  Element Description - A RegistryObjectType instance MAY have textual description in a human readable and user-friendly form. This element is of type InternationalStringType and therefor capable of containing textual values in multiple local languages and character sets.

●  Element ExternalIdentifier - A RegistryObjectType instance MAY have zero or more ExternalIdentifier instances that are composed within the RegistryObject. An ExternalIdentifier instance represents an alternate identifier for the RegistryObject in addition to the identifier specified by its id attribute value.

●  Attribute lid - A RegistryObjectType instance MUST have a lid (Logical Id) attribute. The lid is used to refer to a logical RegistryObject in a version independent manner.

○  All versions of a RegistryObject MUST have the same value for the lid attribute. Note that this is in contrast with the id attribute that MUST be unique for each version of the same logical RegistryObject.

○  The lid attribute MUST be specified by the client when creating the original version of a RegistryObject.

○  The lid attribute specified when submitting the original version of a RegistryObject MUST be globally unique and MUST NOT be already in use as lid by another object.

●  Element Name - A RegistryObjectType instance MAY have a human readable name. The name does not need to be unique with respect to other RegistryObjectType instances. This element is of type InternationalStringType and therefor capable of containing textual values in multiple local languages and character sets.

●  Attribute objectType - A RegistryObjectType instance has an objectType attribute.

○  The value of the objectType attribute MUST be a reference to a ClassificationNode in the canonical ObjectType ClassificationScheme.

○  A server MUST support the object types as defined by the canonical ObjectType ClassificationScheme. The canonical ObjectType ClassificationScheme may easily be extended by adding additional ClassificationNodes to the canonical ObjectType ClassificationScheme.

○  The objectType attribute MUST be assigned by the server for all RegistryObjectType instances that are not instances of ExtrinsicObjectType.

○  The objectType attribute MAY be assigned by the client for all RegistryObjectType instances that are instances of ExtrinsicObjectType

○  If the client does not specify an objectType for an ExtrinsicObject then the server MUST set its value to the id of the ClassificationNode representing ExtrinsicObject within the  canonical ObjectType ClassificationScheme.

○  A server MUST set the correct objectType on a RegistryObject when returning it as a response to a client request.

●  Attribute owner – Specifies the identifier associated with the registered user that owns the RegistryObjectType instance. It is used for access control and may be referenced within custom access control policies.

●  Attribute status - A RegistryObjectType instance MUST have a life cycle status indicator. The status is assigned by the server. Profiles MAY define additional status values if needed as slots on the RegistryObjectType instance.  Such slots SHOULD have a type attribute with value “urn:oasis:names:tc:ebxml-regrep:rim:Slot:type:status”.

○  A server MUST set the correct status on a RegistryObject when returning it as a response to a client request.

○  A client SHOULD NOT set the status on a RegistryObject when submitting the object as this is the responsibility of the server.

○  A server MUST ignore the status on a RegistryObject when it is set by the client during submission or update of the object.

○  The value of the status attribute SHOULD be a reference to a ClassificationNode in the canonical StatusType ClassificationScheme.

○  A Registry MUST support the status types as defined by the StatusType ClassificationScheme. The canonical StatusType ClassificationScheme MAY easily be extended by adding additional ClassificationNodes to the canonical StatusType ClassificationScheme.

●  Element VersionInfo - Provides information about the specific version of a RegistryObjectType instance. The VersionInfo element is set by the server.

○  A server MUST set a VersionInfo element for a RegistryObjectType instance. The  VersionInfo element MUST contain a versionName attribute whose value MUST be unique for all versions of that logical RegistryObjectType.

2.8   VersionInfoType

This type represents information about a specific version of a RegistryObject or RepositoryItem. It is used as type for the RegistryObjectType/VersionInfo and ExtrinsicObjectType/ContentVersionInfo elements in the rim.xsd schema.

2.8.1   Syntax

2.8.2   Example

2.8.3   Description

Node	Type	Cardinality	Default Value	Specified By	Mutable
userVersionName	LongText	0..1		Client	Yes
versionName	String16	0..1		Server	No

 

●  Attribute userVersionName - Represents a client-specified version name associated with the VersionInfo for a specific RegistryObject version

○  A client MAY directly provide a value for the userVersionName attribute when submitting or updating an object

○  A server MUST persist any client specified userVersionName for an object without altering it in any form

●  Attribute versionName - Represents the registry assigned version name identifying the VersionInfo for a specific RegistryObject version.

○  The value for this attribute SHOULD NOT be specified by the client

○  A server MAY silently ignore the value for this attribute if specified by the client

○  The value for this attribute MUST be automatically generated by the server and MUST be defined for RegistryObjectType instances returned by server responses. The server is free to choose any scheme for generating the value for this attribute as long as the value is uniquely identifies a version for objects that have the same lid attribute value.

2.9   objectReferenceType

Base Type: xs:string

A RegistryObjectType instance typically has several references to other RegistryObjectType instances. These references are represented by attributes of type rim:objectReferenceType within the XML Schema for ebXML RegRep.

The RegistryObjectType instance that has a reference to another RegistryObjectType instance is referred to as the reference source object. The RegistryObjectType instance that is being referenced is referred to as the reference target object.

2.9.1   Syntax

2.9.2   Example

 

2.9.3   Description

Local and Remote References

The reference source and target objects MAY be in different ebXML RegRep servers. In such cases the reference is referred to as a remote reference.

Static and Dynamic References

When a reference is fixed to a specific reference target it is referred to as a static reference. This specification also supports a dynamic reference where the reference target is determined dynamically by a query at the time the reference is resolved. Such a reference is referred to as a dynamic reference.

Both static and dynamic references may be to a local or remote object. Static references to local reference targets are the most typical form of reference.

Encoding of objectReferenceType

A client MUST specify values for reference attributes of type objectReferenceType to be encoded as described below:

●  A static reference to a local reference target SHOULD be encoded as the value of the id attribute of the reference target.
The following example shows the reference attribute named primaryContact within Organization element. Its value is the value of the id attribute of a Person element.

 

●  A dynamic reference to a local reference target SHOULD be encoded to contain the id of a DynamicObjectRefType instance. The reference target is determined by the singleton result returned by the Query within the DynamicObjectRef instance.

The following example shows the reference attribute named primaryContact within Organization element. Its value is the value of the id attribute of a DynamicObjectRefType instance. The DynamicObjectRefType instance has a Query that gets the latest version of the object identified by the lid parameter of the Query. The query when invoked matches the latest version of the Person object representing Danyal.

 

●  A static or dynamic reference to a local reference target MAY be encoded to contain a Canonical URL for the local object as defined by the REST binding in [regrep-rs-v4.0].

●  A static or dynamic reference to a remote reference target MUST be  encoded to contain a Canonical URL for the local object as defined by the REST binding in [regrep-rs-v4.0].

The following example shows the reference attribute named primaryContact within Organization element. Its value is the HTTP GET URL for a remote PersonType instance. Note that the URL is not encoded to handle special characters for sake of clarity.

 

2.10   ObjectRefType

Base Type: ExtensibleObjectType

This type represents an object reference as does the objectReferenceType. However, the two are used in different situations. The objectReferenceType is used as the type for all reference attributes in ebRIM. The ObjectRefType is used as type for elements rather than attributes. This type is used when there is a need to have multiple object references within a schema type. An example of this is the ObjectRefList element which is used in several places in the schema where a list of references to RegistryObjectType instances are needed.

2.10.1        Syntax

2.10.2        Description

Node	Type	Cardinality	Default Value	Specified By	Mutable
id	objectReferenceType	1		Client	Yes

 

●  Attribute id - Every ObjectRef instance MUST have an id attribute. The id attribute MUST contain the value of the id attribute of the RegistryObject being referenced.

2.11     DynamicObjectRefType

Base Type: ObjectRefType

This type represents a dynamic object reference. It extends the ObjectRefType and add a Query sub-element. This query is used to determine the reference target at the time the reference is resolved.

2.11.1        Syntax

2.11.2        Description

Node	Type	Cardinality	Default Value	Specified By	Mutable
Query	QueryType	1		Client	Yes

 

●  Element Query – Specifies the query that MUST be invoked in order to determine the reference target.

○  This query MUST match zero or one RegistryObjectType instances.

○  When the query matches zero RegistryObjectType instances, the dynamic object reference is considered to be unresolved.

○  A server MUST return a ConfigurationException fault message if the query matches more than 1 RegistryObjectType instances.

2.12   ExtrinsicObjectType

Base Type: RegistryObjectType

This type is a common base type for new extended types defined by profiles of ebRIM or by clients. The ExtrinsicObjectType also allows arbitrary content to be associated with it. Such arbitrary content is referred to as a Repository Item.

2.12.1        Syntax

2.12.2        Example

2.12.3        Description

Node	Type	Cardinality	Default Value	Specified By	Mutable
ContentVersionInfo	VersionInfoType	0..1		Server	No
mimeType	LongText	0..1	application/octet-stream	Client	No
RepositoryItem	xs:base64Binary	0..1		Client	Yes
RepositoryItemRef	SimpleLinkType	0..1		Client	No

 

●  Element ContentVersionInfo - Provides information about the specific version of a RepositoryItem that is associated with an ExtrinsicObjectType instance. The ContentVersionInfo element is set by the server.

○  A server MUST NOT set a ContentVersionInfo element for an ExtrinsicObjectType instance that does not have a RepositoryItem.

○  A server MUST set a ContentVersionInfo element for an ExtrinsicObjectType instance that has a RepositoryItem. The  ContentVersionInfo element MUST contain a versionName attribute whose value MUST be unique for all versions of that RepositoryItem.

●  Attribute mimeType - An ExtrinsicObjectType instance MAY have a mimeType attribute defined. The mimeType provides information on the type of repository item cataloged by the ExtrinsicObject instance. The value of this attribute SHOULD be a registered MIME media type at http://www.iana.org/assignments/media-types.

●  Element repositoryItem – Provides a base64 binary encoded representation of the repository item associated with the ExtrinsicObjectType instance (if any).

●  Element repositoryItemRef – This element MAY be specified as an alternative to the repositoryItem element. Its type is SimpleLinkType. It uses xlink:simpleAttrs to specify a reference to a file on the client's local file system. This provides client libraries an alternative way to specify local files as repository item. The client library MUST convert a repositoryItemRef element to a repositoryItem element prior to submitting it to the server.

2.13   CommentType

Extends:ExtrinsicObjectType

This type represents a comment that may be associated with a RegistryObjectType instance. A comment associated with a RegistryObject models the familiar yellow POST-IT note metaphor used in attaching comments to paper documents.

2.13.1        Syntax

2.13.2        Example

2.13.3        Description

No new attributes or elements are added by this type. The following requirements are defined for this type:

●  An authorized client MAY attach one or more comments to any RegistryObjectType instance using an Association between the RegistryObjectType instance and the CommentType instance

○  Since a CommentType is itself a RegistryObjectType, a client MAY attach one or more comments to any CommentType instance

●  The type of the Association MUST reference the canonical HasComment ClassificationNode within the Canonical AssociationType ClassificationScheme

●  The sourceObject of the Association MUST be the RegistryObjectType instance

●  The targetObject of the Association MUST be the CommentType instance

2.14   RegistryPackageType

Extends:RegistryObjectType

This type allows for grouping of related RegistryObjectType instances. It serves a similar role as a folder in the familiar file-folder metaphor available in most operating systems.

●  A RegistyObjectType instance MAY be a member of multiple RegistryPackageType instances.

●  A RegistryPackageType instance MAY have multiple RegistryObjectType instances as its members.

●  Membership of a RegistryObjectType instance in a RegistryPackageType instance is established via an AssociationType instance where the type attribute references the canonical “HasMember” AssociationType within the canonical AssociationTypeScheme ClassificationScheme.

●  As a convenience, the RegistryPackageType allows a RegistryObjectList to be specified by the client as a sub-element during submission of a RegistryPackage. The RegistryObjectList contains the set of RegistryObjectType instances that are members of the RegistryPackageType instance.

2.14.1        Syntax

2.14.2        Example

The following example shows the use of a RegistryObjectList to specify the members of a RegistryPackageType instance during submission.

 

The following example shows the equivalent syntax for representing the membership relationship between a RegistryPackage and its members. This representation uses “HasMember” AssociationType instances to establish the membership relationship.

 

 

2.14.3        Description

Node	Type	Cardinality	Default Value	Specified By	Mutable
RegistryObjectList	RegistryObjectListType	0..1		Client	Yes

●  Element RegistryObjectList – This element allows clients to specify members of the RegistryPackage instance using a simpler alternative to “HasMember” AssociationType instances.

○  A server MUST replace the RegistryObjectList with AssociationType instances such that each RegistryObjectType instance is replaced with an AssociationType instance with type “urn:oasis:names:tc:ebxml-regrep:AssociationType:HasMember”, with sourceObject specifying the id of the RegistryPackage instance and with targetObject specifying the id of the RegistryObjectType instance

2.15   ExternalIdentifierType

Base Type: RegistryObjectType

This type allows any number of additional identifiers to be specified for a RegistryObjectType instance. The identifier value is defined using the value attribute within the context of a ClassificationScheme referenced via the identificationScheme attribute.

2.15.1        Syntax

2.15.2        Example

The following examples shows an Organization instance with its tax payer id specified using an ExternalIdentifierType instance.

2.15.3        Description

Node	Type	Cardinality	Default Value	Specified By	Mutable
identificationScheme	objectReferenceType	1		Client	Yes
registryObject	objectReferenceType	0..1		Client	No
value	LongText	1		Client	Yes

 

●  Attribute identificationScheme - Each ExternalIdentifier instance MUST have an identificationScheme attribute that references a ClassificationScheme. This ClassificationScheme defines the namespace within which an identifier is defined using the value attribute for the RegistryObjectType instance referenced by the RegistryObject attribute.

●  Attribute registryObject - Each ExternalIdentifier instance MAY have a registryObject attribute specified. This attribute references the parent RegistryObjectType instance for which this is an ExternalIdentifier.

○  This attribute MUST be specified when a client submits an ExternalIdentifier separately from its parent RegistryObjectType instance

○  This attribute MAY be unspecified when a client submits an ExternalIdentifier as a sub-element of its parent RegistryObjectType instance. In such cases the server MUST set this attributes value to the value of the id attribute of the parent RegistryObjectType instance.

○  Attribute value - Each ExternalIdentifier instance MUST have a value attribute that provides the identifier value for this ExternalIdentifier (e.g., the tax payer id in example above).

2.16   ExternalLinkType

Base Type: RegistryObjectType

This type allows a link to external content to be added to a RegistryObjectType instance.

2.16.1        Syntax

2.16.2        Example

The following examples shows an Organization instance with an ExternalLink that links to its web site URL via its ExternalRef sub-element.

2.16.3        Description

Node	Type	Cardinality	Default Value	Specified By	Mutable
ExternalRef	SimpleLinkType	1		Client	Yes
registryObject	objectReferenceType	0..1		Client or Server	No

 

●  Element ExternalRef - Each ExternalLink instance MUST have an ExternalRef sub-element defined. This element provides a URI to the external resource pointed to by this ExternalLink instance.

●  Attribute registryObject – references the parent RegistryObjectType instance within which the ExtrnalLinkType instance is composed. The value MUST be provided by client when an ExtrenalLink is submitted separate from its parent object. The value MUST be set by the server if the ExternalLink is submitted as part of the submission of its parent object.

A RegistryObjectType instance MAY be associated or related with zero or more RegistryObjectType instances. The information model defines the AssociationType type, an instance of which MAY be used to associate any two RegistryObjectType instances. It also defines an Association element for that type.

In the example below, an AssociationType instance with type “...Supercedes” is used to indicate that the NAICS2001 ClassificationScheme supercedes the NAICS1997 ClassificationScheme.

3.1   Source and Target Objects

An AssociationType instance represents an association between a source RegistryObjectType instance and a target RegistryObjectType instance. These are referred to as sourceObject and targetObject for the AssociationType instance. It is important which object is the sourceObject and which is the targetObject as it determines the directional semantics of an Association.

3.2   Type of an Association

An AssociationType instance MUST have a type attribute that identifies the type of that association. The value of this attribute is typically the id of a ClassificationNode under the canonical AssociationType ClassificationScheme.

3.3   AssociationType

Base Type: RegistryObjectType

3.3.1   Syntax

3.3.2   Example

The following examples shows an Organization instance that has an “OffersService” association with a Service that it offers.

3.3.3   Description

Node	Type	Cardinality	Default Value	Specified By	Mutable
sourceObject	objectReferenceType	1		Client	Yes
targetObject	objectReferenceType	1		Client	Yes
type	objectReferenceType	1		Client	Yes

 

●  Attribute sourceObject - Each Association MUST have a sourceObject attribute that references the RegistryObjectType instance that is the source of that Association.

●  Attribute targetObject - Each Association MUST have a targetObject attribute that references the RegistryObjectType instance that is the target of that Association.

●  Attribute type - Each Association MUST have a type attribute that identifies the type of that association.

○  The value of the type attribute MUST be a reference to a ClassificationNode within the canonical AssociationType ClassificationScheme. 

○  A server MUST support the canonical association types as defined by the canonical AssociationType ClassificationScheme. Deployments and profiles may extend the canonical AssociationType ClassificationScheme by adding additional ClassificationNodes to it.

3.4   Access Control

A client MAY create an AssociationType instance between any two RegistryObjectType instances   assuming the access control policies associated with the source and target object permit the client to create a reference to them. The default access control policy permits any client to create a reference to an object.

The ebRIM information model supports classification of RegistryObjectType instances using values defined by a taxonomy or controlled vocabulary. A taxonomy is represented in ebRIM by the ClassificationSchemeType type. Values in a taxonomy are represented by the ClassificationNode type. A classification instance is represented in ebRIM by the ClassificationType type.

This specification specifies a set of canonical ClassificationSchemes. Deployments and profiles MAY extends these canonical ClassificationSchemes by adding additional ClassificationNodes to them. They MAY also define new ClassificationSchemes. A RegistryObjectType instance MAY be classified using any ClassificationNode in any ClassificationScheme supported by the server. A RegistryObjectType instance MAY have any number of classifications defined for it.

A general ClassificationScheme can be viewed as a tree structure where the ClassificationScheme is the root and ClassificationNodes are either intermediate or leaf nodes in the tree.

Illustration 4 below shows RegistryObjectType instances representing Organizations as grey boxes. Each Organization represents an automobile manufacturer. Organization is classified by the ClassificationNode named “Automotive” under the ClassificationScheme instance with name “IndustryScheme”. Furthermore, the US Automobile manufacturers are classified by the “US” ClassificationNode under the ClassificationScheme with name “GeographyScheme”. Similarly, a European automobile manufacturer is classified by the “Europe” ClassificationNode under the ClassificationScheme with name “GeographyScheme”.

The example shows how a RegistryObject may be classified by multiple ClassificationNodeType instances under multiple ClassificationScheme instances (e.g., IndustryScheme, GeographyScheme).

 

 

Illustration 5 shows the Classification information model.

 

 

4.1   TaxonomyElementType

Base Type: RegistryObjectType

This abstract type is the common base type for ClassificationSchemeType and ClassificationNodeType.

4.1.1   Syntax

4.1.2   Description

Node	Type	Cardinality	Default Value	Specified By	Mutable
ClassificationNode	ClassificationNodeType	0..*		Client	Yes

 

●  Element ClassificationNode – This element represents a ClassificationNode child of a parent TaxonomyElementType instance. A TaxonomyElementType instance MAY have any number of  ClassificationNode child elements.

4.2   ClassificationSchemeType

Base Type: TaxonomyElementType

A ClassificationScheme instance represents a taxonomy.

The taxonomy hierarchy may be defined internally to the server using instances of ClassificationNodeType type, or it may be defined externally to the server, in which case the structure and values of the taxonomy elements are not known to the Registry.

In the first case the classification scheme is said to be internal and in the second case the classification scheme is said to be external.

4.2.1   Syntax

4.2.2   Example

The following examples shows a ClassificationScheme representing gender values.

4.2.3   Description

Node	Type	Cardinality	Default Value	Specified By	Mutable
isInternal	xs:boolean	1		Client	No
nodeType	objectReferenceType	1		Client	No

 

●  Attribute isInternal - When submitting a ClassificationSchemeType instance the client MUST declare whether the ClassificationSchemeType instance represents an internal or an external taxonomy. This allows the server to validate the subsequent submissions of ClassificationNodeType and ClassificationType instances in order to maintain the type of ClassificationScheme consistent throughout its lifecycle.

●  Attribute nodeType - When submitting a ClassificationScheme instance the client MUST declare the structure of taxonomy nodes within the ClassificationScheme via the nodeType attribute. The value of the nodeType attribute MUST be a reference to a ClassificationNodeType instance within the canonical NodeType ClassificationScheme. A server MUST support the node types as defined by the canonical NodeType ClassificationScheme. The canonical NodeType ClassificationScheme MAY easily be extended by adding additional ClassificationNodes to it.

The following table lists the canonical ClassificationNode defined as values for the NodeType ClassificationScheme:

 

Name	Description
UniqueCode	Indicates that the code for each ClassificationNode in the ClassificationScheme is unique within the scope of the ClassificationScheme
EmbeddedPath	Indicates that the code assigned to each node of the taxonomy also encodes its path.
NonUniqueCode	Indicates that the code for each ClassificationNode in the ClassificationScheme is not unique within the scope of the ClassificationScheme. For example, in a geography taxonomy Moscow could be under both Russia and the USA, where there are five cities of that name in different states.

 

4.3   ClassificationNodeType

Base Type: TaxonomyElementType

ClassificationNodeType instances are used to define values for a taxonomy represented by ClassificationSchemeType instance.

4.3.1   Syntax

4.3.2   Description

Node	Type	Cardinality	Default Value	Specified By	Mutable
code	LongText	1		Client	No
parent	objectReferenceType	0..1		Client	No
path	xs:string	0..1		Registry	No

 

●  Attribute code - A ClassificationNodeType instance MUST have a code attribute. The code attribute contains a code that represents a value within a ClassificationScheme.

○  The code attribute of a ClassificationNodeType instance MUST be unique with respect to all sibling ClassificationNodes that are immediate children of the same parent TaxonomyElementType instance.

●  Attribute parent - A ClassificationNodeType instance MAY have a parent attribute. The parent attribute references the parent TaxonomyElementType instance. This is either another ClassificationNodeType instance or the ClassificationSchemeType instance.

●  Attribute path - A ClassificationNodeType instance MAY have a path attribute. The path attribute represents a hierarchical path from the root ClassificationSchemeType to the ClassificationNodeType instance. The syntax of the path attribute value is defined in 4.3.3.

○  A server MUST set the path attribute for any ClassificationNodeType instance when it is submitted by a client.

○  The path attribute MUST be ignored by the server if it is specified by the client during the submission of the ClassificationNodeType instance. 

○  The path attribute of a ClassificationNode MUST be unique within a server.

4.3.3    Canonical Path Syntax

The path attribute of the ClassificationNodeType instance contains an absolute path in a canonical representation that uniquely identifies the path leading from the root ClassificationSchemeType instance to that ClassificationNodeType instance.

The canonical path representation is defined by the following BNF grammar:

 

In the above grammar, rootTaxonomyElementId is the id attribute of the root ClassificationSchemeType or ClassificationNodeType instance, and nodeCode is defined by NCName production as defined by http://www.w3.org/TR/REC-xml-names/#NT-NCName.

Example of Canonical Path Representation

The following canonical path represents the path attribute value for the ClassificationNode with code “Male” in the sample Gender ClassificationScheme presented earlier.

 

4.4    ClassificationType

Base Type: RegistryObjectType

A ClassificationType instance classifies a RegistryObjectType instance by using a value defined within a particular ClassificationScheme. An internal Classification specifies the value by referencing the ClassificationNodeType instance within a ClassificationSchemeType instance. An external Classification  specifies the value using a string value that is defined in some external specification represented by an external ClassificationSchemeType instance.

4.4.1   Syntax

4.4.2   Example

The following examples shows how a Person instance is classified using the sample Gender ClassificationScheme used in earlier examples.

 

4.4.3   Description

Node	Type	Cardinality	Default Value	Specified By	Mutable
classificationNode	objectReferenceType	0..1		Client	No
classifiedObject	objectReferenceType	0..1		Client	No
classificationScheme	objectReferenceType	0..1		Client	No
nodeRepresentation	LongText	0..1		Client	No

 

●  Attribute classificationNode - If the ClassificationType instance represents an internal classification, then the classificationNode attribute is required.

○  The classificationNode value MUST reference a ClassificationNodeType instance.

●  Attribute classifiedObject - For both internal and external classifications, the classifiedObject attribute is required and it references the RegistryObjectType instance that is classified by this Classification.

●  Attribute classificationScheme - If the ClassificationType instance represents an external classification, then the classificationScheme attribute is required.

○  The classificationScheme value MUST reference a ClassificationScheme instance.

●  Attribute nodeRepresentation - If the ClassificationType instance represents an external classification, then the nodeRepresentation attribute is required. It is a representation of a taxonomy value from a classification scheme.

●  A canonical slot with name “urn:oasis:names:tc:ebxml-regrep:rim:Classification:context” may be optionally specified to provide additional context for a ClassificationType instance

The term provenance in the English language implies the origin and history of ownership and custodianship of things of value. When applied to the ebXML RegRep, provenance implies information about the origin, history of ownership, custodianship, and other relationships between entities such as people, organizations and information represented by RegistryObjectType instances.

The ebRIM information model supports types and relationships that MAY be used to represent the provenance of RegistryObjectType instances.

The following figure presents the significant types defined by the provenance information model.

5.1   PostalAddressType

Base Type: ExtensibleObjectType

This type represents a postal or mailing address.

5.1.1   Syntax

5.1.2   Example

5.1.3   Description

Node	Type	Cardinality	Default Value	Specified By	Mutable
city	ShortText	No		Client	Yes
country	ShortText	No		Client	Yes
postalCode	ShortText	No		Client	Yes
stateOrProvince	ShortText	No		Client	Yes
street	ShortText	No		Client	Yes
streetNumber	String32	No		Client	Yes

 

●  Attribute city - A PostalAddressType instance MAY have a city attribute identifying the city for that address.

●  Attribute country - A PostalAddressType instance MAY have a country attribute identifying the country for that address.

●  Attribute postalCode - A PostalAddressType instance MAY have a postalCode attribute identifying the postal code (e.g., zip code) for that address.

●  Attribute stateOrProvince - A PostalAddressType instance MAY have a stateOrProvince attribute identifying the state, province or region for that address.

●  Attribute street - A PostalAddressType instance MAY have a street attribute identifying the street name for that address.

●  Attribute streetNumber - A PostalAddressType instance MAY have a streetNumber attribute identifying the street number (e.g., 65) for the street address.

5.2   TelephoneNumberType

Base Type: ExtensibleObjectType

This type defines attributes of a telephone number.

5.2.1   Syntax

5.2.2   Example

5.2.3   Description

Node	Type	Cardinality	Default Value	Specified By	Mutable
areaCode	String8	0..1		Client	Yes
countryCode	String8	0..1		Client	Yes
extension	String8	0..1		Client	Yes
number	String16	0..1		Client	Yes
type	objectReferenceType	0..1		Client	Yes

 

●  Attribute areaCode - A TelephoneNumberType instance MAY have an areaCode attribute that provides the area code for that telephone number.

●  Attribute countryCode - A TelephoneNumberType instance MAY have a countryCode attribute that provides the country code for that telephone number.

●  Attribute extension - A TelephoneNumberType instance MAY have an extension attribute that provides the extension number, if any, for that telephone number.

●  Attribute number - A TelephoneNumberType instance MAY have a number attribute that provides the local number (without area code, country code and extension) for that telephone number.

●  Attribute type - A TelephoneNumberType instance MAY have a type attribute that provides the type for the TelephoneNumber. The value of the phoneType attribute MUST be a reference to a ClassificationNode in the canonical PhoneType ClassificationScheme.

5.3   EmailAddressType

Base Type: ExtensibleObjectType

This type defines attributes of an email address.

5.3.1   Syntax

5.3.2   Example

5.3.3   Description

Node	Type	Cardinality	Default Value	Specified By	Mutable
address	ShortText	1		Client	Yes
type	objectReferenceType	0..1		Client	Yes

 

●  Attribute address - An EmailAddressType instance MUST have an address attribute that provides the actual email address.

●  Attribute type - An EmailAddressType instance MAY have a type attribute that provides the type for that email address. The value of the type attribute MUST be a reference to a ClassificationNode in the canonical EmailType ClassificationScheme.

5.4   PartyType

Base Type: RegistryObjectType

This abstract type represents a party that has contact information such as PostalAddress, EmailAddress, TelephoneNumber etc. It is used as a common base type for PersonType and OrganizationType.

5.4.1   Syntax

5.4.2   Description

Node	Type	Cardinality	Default Value	Specified By	Mutable
EmailAddress	EmailAddressType	0..*		Client	Yes
PostalAddress	PostalAddressType	0..*		Client	Yes
TelephoneNumber	TelephoneNumberType	0..*		Client	Yes

 

●  Element EmailAddress - A PartyType instance MAY have any number of EmailAddress sub-elements. Each EmailAddress provides an email address for that PartyType instance. A PartyType instance SHOULD have at least one EmailAddress.

●  Element PostalAddress - A PartyType instance MAY have any number of PostalAddress sub-elements. Each PostalAddress element provides a postal address for that PartyType instance. A PartyType instance SHOULD have at least one PostalAddress.

●  Element TelephoneNumber - A PartyType instance MAY have any number of TelephoneNumber sub-elements. Each TelephoneNumber element provides a TelephoneNumber for that PartyType instance. A PartyType instance SHOULD have at least one TelephoneNumber.

5.5   PersonType

Base Type: PartyType

This type represent a person.

5.5.1   Syntax

5.5.2   Example

5.5.3   Description

Node	Type	Cardinality	Default Value	Specified By	Mutable
PersonName	PersonNameType	0..1		Client	No

 

●  Element PersonName – A PersonType instance SHOULD have a PersonName sub-element that provides the name for that person.

5.6   PersonNameType

Base Type: ExtensibleObjectType

This represents the name for a PersonType instance.

5.6.1   Syntax

5.6.2   Example

5.6.3   Description

Node	Type	Cardinality	Default Value	Specified By	Mutable
firstName	ShortText	0..1		Client	Yes
lastName	ShortText	0..1		Client	Yes
middleName	ShortText	0..1		Client	Yes

 

●  Attribute firstName - A PersonName instance SHOULD have a firstName attribute that is the given name of the person.

●  Attribute lastName - A PersonName instance SHOULD have a lastName attribute that is the family name of the person.

●  Attribute middleName - A PersonName instance SHOULD have a middleName attribute that is the middle name of the person.

5.7   OrganizationType

Base Type: PartyType

This type represents an organization or entity.

5.7.1   Syntax

5.7.2   Example

5.7.3   Description

Node	Type	Cardinality	Default Value	Specified By	Mutable
Organization	OrganizationType	0..*		Client	Yes
primaryContact	objectReferenceType	0..1		Client	Yes

 

●  Element Organization – This element allows clients to specify sub-organizations of the Organization instance using a simpler alternative to specifying “HasMember” AssociationType instances between the parent and child Organizations.

○  A server MUST replace any nested Organization elements within an OrganizationType instance with AssociationType instances such that each nested Organization element is replaced with an AssociationType instance with type “urn:oasis:names:tc:ebxml-regrep:AssociationType:HasMember”, with sourceObject specifying the id of the parent OrganizationType instance and with targetObject specifying the id of the nested Organization element

●  Attribute primaryContact - An OrganizationType instance SHOULD have a primaryContact attribute that references the Person instance for the person that is the primary contact for that organization.

5.8   Associating Organization With Persons

There are many situation where a person is related to an organization. Such relationship SHOULD be defined by AssociationType instances between an OrganizationType instance and a PersonType instance as follows:

●  The type attribute of the Association references the canonical ClassificationNode with id “urn:oasis:names:tc:ebxml-regrep:AssociationType:AffiliatedWith” or one of its descendants.

●  The sourceObject references the PersonType instance.

●  The targetObject references the OrganizationType instance.

5.9   Associating Organization With Organizations

There are many situation where an organization is related to another organization. Such relationship SHOULD be defined by AssociationType instances between an OrganizationType instance and another OrganizationType instance.

●  To represent parent-child relationship between organizations the type attribute of the Association SHOULD reference the canonical ClassificationNode with id “urn:oasis:names:tc:ebxml-regrep:AssociationType:HasMember” or one of its descendants.

●  The sourceObject SHOULD reference the parent OrganizationType instance.

●  The targetObject SHOULD reference the child OrganizationType instance.

5.10   Associating Organizations With RegistryObjects

An organization MAY be associated with zero or more RegistryObjectType instances. Each such association is modeled in ebRIM using an Association instance between an Organization instance and a RegistryObjectType instance.

Associations between Organizations and RegistryObjectType instances do not entitle organizations to any special privileges with respect to those instances. Such privileges are defined by the Access Control Policies defined for the RegistryObjectType instances as described in the Access Control Information Model chapter.

This chapter describes the parts of the information model that support the description of services within an ebXML RegRep server. Although service information model aligns with [WSDL2] model, it may be used to  describe any type of service in addition to web services.

 

6.1   ServiceType

Base Type: RegistryObjectType

This type represent a logical service. Physical service endpoints are represented by the ServiceEndpointType type. A ServiceType instance typically contains ServiceEndpoint sub-elements where each ServiceEndpoint sub-element represents an alternate endpoint for a service.

6.1.1   Syntax

6.1.2   Example

6.1.3   Description

Node	Type	Cardinality	Default Value	Specified By	Mutable
ServiceEndpoint	ServiceEndpointType	0..*		Client	Yes
serviceInterface	objectReferenceType	0..1		Client	Yes

 

●  Element ServiceEndpoint – Represents a physical endpoint for the service that MAY be used by clients to access the service

●  Attribute serviceInterface – References the abstract interface description for the service

○  MUST reference a ServiceInterfaceType instance if specified

6.2   ServiceEndpointType

Base Type: RegistryObjectType

This type represents a physical endpoint for the service that MAY be used by clients to access a service.

6.2.1   Syntax

6.2.2   Example

6.2.3   Description

Node	Type	Cardinality	Default Value	Specified By	Mutable
address	xs:anyURI	0..1		Client	Yes
serviceBinding	objectReferenceType	0..1		Client	Yes

 

●  Attribute address – Represents the endpoint address URI that a client of the service endpoint may use to access the service endpoint

●  Attribute serviceBinding – References the ServiceBindingType instance that represents protocol-specific binding information for the ServiceEndpointType instance

○  MUST reference a ServiceBindingType instance

6.3   ServiceBindingType

Base Type: RegistryObjectType

This type represents protocol-specific binding information for a ServiceEndpointType instance. Example of a protocol-specific binding is a SOAP binding.

6.3.1   Syntax

6.3.2   Example

6.3.3   Description

Node	Type	Cardinality	Default Value	Specified By	Mutable
serviceInterface	objectReferenceType	0..1		Client	Yes

 

●  Attribute serviceInterface – References a ServiceInterfaceType instance which represents the abstract service interface for the service

○  MUST reference a ServiceInterfaceType instance if specified

6.4   ServiceInterfaceType

Base Type: RegistryObjectType

This type represents an abstract service interface for a service.

6.4.1   Syntax

6.4.2   Example

6.4.3   Description

No attributes or elements beyond those inherited from RegistryObjectType are defined for this type.

This chapter describes the information model for defining and invoking parameterized queries in ebXML RegRep. The following significant types are defined by the Query Information Model:

●  QueryDefinitionType - Represents the definition of a parameterized query

●  QueryType – Represents the invocation of a parameterized query

Several canonical QueryDefinitionType instances are defined by the ebRS specification. Profiles of ebXML RegRep MAY define additional QueryDefinitionType instances as canonical queries for that profile. Deployments MAY also define additional QueryDefinitionType instances. Finally, clients MAY submit additional QueryDefinitionType instances.

A QueryDefinitionType instance MAY be invoked using a QueryType instance. The ebRS Query protocol allows clients to invoke a QueryDefinitionType instance using a  QueryType instance within the Query protocol.

The following figure presents the significant types defined by the Query information model.

7.1   QueryDefinitionType

Base Type: RegistryObjectType

This type represents the definition of a parameterized query. The definition of a query includes the definition of its supported parameters and the definition of a parameterized query expression.

7.1.1   Syntax

7.1.2   Example

7.1.3   Description

Node	Type	Cardinality	Default Value	Specified By	Mutable
Parameter	ParameterType	0..*		Client	Yes
QueryExpression	QueryExpressionType	0..1		Client	Yes

 

●  Element Parameter – Represents the definition of a query parameter for the QueryDefinitionType instance. A QueryDefinitionType instance MAY have any number of Parameter sub-elements

●  Element QueryExpression – Represents a query expression for the parameterized query.

○  MAY be omitted if the query is implemented as a Query plugin as defined by ebRS

7.2   ParameterType

Base Type: ExtensibleObjectType

This type represents the definition of a parameter within a QueryDefinitionType.

7.2.1   Syntax

7.2.2   Example

7.2.3   Description

Node	Type	Cardinality	Default Value	Specified By	Mutable
dataType	xs:string	1		Client	Yes
defaultValue	xs:string	0..1		Client	Yes
Description	InternationalStringType	0..1		Client	Yes
minOccurs	xs:nonNegativeInteger	0..1	1	Client	Yes
maxOccurs	xs:nonNegativeInteger	0..1	1	Client	Yes
Name	InternationalStringType	1		Client	Yes
parameterName	xs:string	1		Client	Yes

 

●  Attribute dataType – Specifies the data type for the parameter.

○  The dataType MUST be “string” for parameters whose values are represented by a string value.

○  The dataType MUST be “boolean” for parameters whose values are represented by a boolean value.

○  The dataType MUST be “taxonomyElement” for parameters whose value is the id of a TaxonomyElement.

●  Attribute defaultValue - Specifies the default value for the parameter. This value MUST be used as parameter value when the query is invoked if the client does not specify a value for this parameter.

●  Element Description - Specifies a human-friendly description of the parameter that indicates  what the parameter value represents and what kind of value is allowed. The description MAY be provided in multiple local languages and character sets.

●  Attribute minOccurs – Specifies the minimum number of values allowed for the parameter.

●  Attribute maxOccurs - Specifies the maximum number of values allowed for the parameter.

●  Element Name - Specifies a human-friendly name for the parameter. The name MAY be provided in multiple local languages and character sets.

●  Attribute parameterName – Specifies the canonical name of the parameter. The canonicalName identifies the parameter in a locale-insensitive manner

○  SHOULD match a declared parameter name within the query expression for the QueryDefinitionType instance

○  The parameterName MUST be unique across the universe of all sibling ParameterType instances within a QueryDefinitionType instance

7.3   QueryExpressionType

Base Type: ExtensibleObjectType

This type represents a query expression in a specified query language that MAY be used by the server to invoke a query.

The QueryExpressionType is the abstract root of a type hierarchy for the following more specialized sub-types:

●  StringQueryExpressionType – This type MAY be used to represent non-XML query syntaxes such as SQL-92 and EJBQL.

●  XMLQueryExpressionType - This type MAY be used to represent XML query syntaxes such as OGC Filter Query.

This specification does not specify a specific query expression syntax that a server must support.

7.3.1   Syntax

7.3.2   Description

Node	Type	Cardinality	Default Value	Specified By	Mutable
queryLanguage	objectReferenceType	1		Client	Yes

 

●  Attribute queryLanguage – Specifies the query language used by the QueryExpressionType instance.

○  MUST be a reference to a ClassificationNode in the canonical Query Language ClassificationScheme whose id is “urn:oasis:names:tc:ebxml-regrep:classificationScheme:QueryLanguage”.

7.4   StringQueryExpressionType

Base Type: QueryExpressionType

This type is used to represent non-XML query syntaxes such as SQL-92 and EJBQL.

7.4.1   Syntax

7.4.2   Example

7.4.3   Description

Node	Type	Cardinality	Default Value	Specified By	Mutable
Value	xs:string	1		Client	Yes

 

●  Element Value – Specifies the string value representing the actual query expression within the query language specified by the queryLanguage attribute inherited from base type QueryExpressionType.

7.5   XMLQueryExpressionType

Base Type: QueryExpressionType

This type is used to represent XML query syntaxes such as OGC Filter Query.

7.5.1   Syntax

7.5.2   Example

7.5.3   Description

An XMLQueryExpressionType instance MAY contain any XML element from a namespace other than the name space for rim.xsd. In the example above we use an ogc:Filter element to represent an OGC Filter query.

7.6   QueryType

Base Type: ExtensibleObjectType

This type represents the invocation of a parameterized query.

7.6.1   Syntax

7.6.2   Example

7.6.3   Description

Node	Type	Cardinality	Default Value	Specified By	Mutable
queryDefinition	objectReferenceType	1		Client	Yes

 

●  Attribute queryDefinition – References the parameterized query to be invoked by the server.

○  The value of this attribute MUST be a reference to a QueryDefinitionType instance that is supported by the server.

●  Element Slot (Inherited) - Each Slot element specifies a parameter value for a parameter supported by the QueryDefinitionType instance.

○  The slot name MUST match a parameterName attribute within a Parameter's definition within the QueryDefinitionType instance.

○  The slot value's type MUST match the dataType attribute for the Parameter's definition within the QueryDefinitionType instance.

○  A server MUST NOT treat the order of parameters as significant.

This chapter defines the information model types that supports the Event Notification feature for ebXML RegRep. These types include the following:

●  AuditableEventType – Represents a server event that is typically a consequence of a client request.

●  SubscriptionType – Represents a client's subscription to receive notification of AuditableEventType instances based upon a specified selection criteria.

●  QueryType – Represents a query invocation that is used to select events of interest within a SubscriptionType instance. This type has been specified previously in the Query Information Model.

●  NotificationType – Represents a notification sent by the server to a client regarding an event that matches the criteria specified by the client within a SubscriptionType instance.

 

Illustration 9 shows how a Subscription may be defined that uses a QueryType instance as a selector query to select the AuditableEvents of interest to the subscriber. The Subscription MAY also have zero or more DeliveryInfoType elements that specify the subscriber's endpoint to deliver the selected events to. The endpoint may be a REST or SOAP service endpoint or it may be an email address endpoint in case notification is to be delivered via email.

8.1   AuditableEventType

Base Type: RegistryObjectType

This type represents a server event. AuditableEventType instances provide a long-term record of events that effected changes in the state of a RegistryObjectType instance. AuditableEventType instances MUST be generated by the server and MUST NOT be submitted by clients.

AuditableEventType instances  represent a change in the state of a RegistryObjectType instance. For example a client request could Create, Update, Deprecate or Delete a RegistryObjectType instance. An AuditableEventType instance is created when a request creates or alters the state of a RegistryObjectType instance. Read-only requests typically do not generate an AuditableEventType instance.

8.1.1   Syntax

8.1.2   Example

The following example shows an AuditableEventType instance that logs the creation of an object within the context of a client request.

8.1.3   Description

Node	Type	Cardinality	Default Value	Specified By	Mutable
Action	ActionType	1..*		Registry	No
requestId	xs:string	1		Registry	No
timestamp	xs:dateTime	1		Registry	No
user	xs:string	1		Registry	No

 

●  Element Action – Represents an action taken by the server within the context of an AuditableEventType instance. An AuditableEventType instance MUST have one or more Action instances.

●  Attribute requestId – Specifies the id of the request that generated the AuditableEventType instance.

●  Attribute timestamp – Specifies the timestamp that represents the date and time the event occurred.

●  Attribute user – Specifies the id of the registered user associated with the client that made the request to the server that generated the AuditableEventType instance. Note that the inherited attribute owner SHOULD be set by a server to an internal system user since it is the server and not the user associated with the request that creates an AuditableEventType instance

8.2   ActionType

Base Type: ExtensibleObjectType

Represents an action taken by the server within the context of an AuditableEventType instance.

8.2.1   Syntax

8.2.2   Description

Node	Type	Cardinality	Default Value	Specified By	Mutable
AffectedObjects	RegistryObjectListType	0..1		Registry	No
AffectedObjectRefs	ObjectRefListType	0..1		Registry	No
eventType	objectReferenceType	1		Registry	No

 

●  Element AffectedObject – Identifies the RegistryObjectType instances that were affected by the event. The AffectedObject element contains any number of elements of type RegistryObjectType, each of which is a RegistryObjectType instance affected by the event. If this element is present then AffectedObjectRefs element MUST NOT be present.

●  Element AffectedObjectRefs – Identifies the RegistryObjectType instances that were affected by the event. The AffectedObject element contains any number of ObjectRef elements each of which reference a RegistryObjectType instance that was affected by the event. If this element is present then AffectedObjects element MUST NOT be present.

●  Attribute eventType – Specifies the type of event associated with the Action within an AuditableEventType instance.

○  The value of the eventType attribute MUST be a reference to a ClassificationNode in the canonical EventType ClassificationScheme.

○  A Registry MUST support the event types as defined by the EventType ClassificationScheme.

○  The canonical EventType ClassificationScheme MAY easily be extended by adding additional ClassificationNodes to it

8.3   SubscriptionType

Base Type: RegistryObjectType

This type represents a subscription on behalf of a client to receive notifications by the server of events that are of interest to the client.

8.3.1   Syntax

8.3.2   Example

The following example shows a subscription to receive notification of changes to the object whose id value matches “urn:acme:person:Danyal”. The DeliveryInfo specifies the SOAP endpoint where the server should deliver the Notification.

8.3.3   Description

Node	Type	Cardinality	Default Value	Specified By	Mutable
DeliverInfo	DeliveryInfoType	0..*		Client	Yes
endTime	xs:dateTime	0..1		Client	Yes
notificationInterval	xs:duration	0..1		Client	Yes
Selector	QueryType	1		Client	Yes
startTime	xs:dateTime	0..1	Time of submission	Client	Yes

 

●  Attribute startTime, endTime – Define the time window within which the subscription is valid.

○  A server MUST use the current time at the time of submission of Subscription as value for the startTime attribute if it is unspecified.

○  The Subscription validity window MUST be inclusive of the startTime and endTime.

○  If endTime is unspecified then a server MUST assume the Subscription is valid at any time   any time since startTime inclusively.

●  Element DeliveryInfo – Specifies the information needed by the server to deliver notifications for the subscription. It includes the reference to the endpoint where notifications should be delivered.

○  A server MUST deliver notifications that match the Selector query for a valid SubscriptionType instance to the endpoint specified by each DeliveryInfo element of the SubscriptionType instance.

○  If no DeliveryInfo element is present then client MUST use the canonical query GetNotification via the Query protocol to “pull” the pending notification if any at a time of their choosing as defined in ebRS.

●  Attribute notificationInterval – Specifies the duration that a server MUST wait between delivering successive notifications to the client. The client specifies this attribute in order to control the frequency of notification communication between server and client.

○  A server MUST deliver any pending notifications within the interval specified by this attribute.

○  A server MUST NOT deliver the same event more than once for the same subscription.

●  Element Selector – Specifies the query that the server MUST invoke to determine whether an event matches a subscription or not. If the result of the query contains an object that is affected by an event that has not yet been delivered to the subscriber then the event matches the subscription.

 

8.4   DeliveryInfoType

Base Type: ExtensibleObjectType

This type provides the information needed by the server to deliver notifications for the subscription. It includes the reference to the endpoint where notifications should be delivered. The endpoint reference is typically one of the following types:

●  SOAP service endpoint

●  REST service endpoint

●  E-mail address endpoint

●  Software plugin endpoint that is configured within the same process as the registry server

8.4.1   Syntax

8.4.2   Description

Node	Type	Cardinality	Default Value	Specified By	Mutable
notificationOption	objectReferenceType	0..1		Client	Yes
NotifyTo	wsa:EndpointReferenceType	1		Client	Yes

 

●  Attribute notificationOption – Specifies the modality of how notifications are to be delivered to the subscriber. Its value MUST reference a ClassificationNode in the canonical NotificationOptionType ClassificationScheme.

○  urn:oasis:names:tc:ebxml-regrep:NotificationOptionType:Objects – Indicates that the server MUST provide complete RegistryObjectType instances in notifications delivered to the subscriber when this mode is specified.

○  urn:oasis:names:tc:ebxml-regrep:NotificationOptionType:ObjectRefs – Indicates that the server MUST provide ObjectRefType instances rather than complete RegistryObjectType instances in notifications delivered to the subscriber when this mode is specified. A client MAY pull the complete RegistryObjectType instances using Query protocol after receiving the notification.

●  Element NotifyTo – Specifies the endpoint reference for the endpoint where the server should deliver notifications for the Subscription.

○  The type of this element is wsa:EndpointReferenceType as defined by [WSA-Core]

○  The NotifyTo element has a <wsa:Address> sub-element

○  The content of the <wsa:Address> element is a string representing the endpoint address which SHOULD be a URI

○  The type of endpoint (SOAP, REST, email, ...) is indicated by an extension attribute rim:endpointType defined on the <wsa:Address> element as follows:

■   If endpoint is a SOAP web service then the rim:endpointType attribute value MUST be “urn:oasis:names:tc:ebxml-regrep:endPointType:soap”

■   If endpoint is a REST web service then the rim:endpointType attribute value MUST be “urn:oasis:names:tc:ebxml-regrep:endPointType:rest”

■   If endpoint is an email address then the rim:endpointType attribute value MUST be “urn:oasis:names:tc:ebxml-regrep:endPointType:mail”

■   If endpoint is a software plugin then the rim:endpointType attribute value MUST be “urn:oasis:names:tc:ebxml-regrep:endPointType:plugin”

 

8.5   NotificationType

Base Type: RegistryObjectType

This type represents a notification that is sent by the server to a client to notify it of server events that are of interest to the client.

 

8.5.1   Syntax

8.5.2   Example

The following example shows a Notification sent by the server for the subscription in earlier example. It notifies the subscriber that the object with id “urn:acme:person:Danyal” has changed.

8.5.3   Description

Node	Type	Cardinality	Default Value	Specified By	Mutable
Event	AuditableEventType	1..*		Server	No
subscription	objectReferenceType	1		Server	No

 

●  Element Event – Represents an Event that is of interest to the subscriber.

○  Unlike an AuditableEvent element that contains all objects affected by it, the Event element MUST only contain objects that match the selector query of the SubscriptionType instance. It has only a subset of affected objects compared to the actual AuditableEvent it represents. The subset of affected objects MUST be those that match the selector query for the subscription.

○  The Action elements within the Event element MUST contain a RegistryObjectList element if subscription's notificationOption is “Push”.

○  The Action elements within the Event element MUST contain a RegistryObjectRefList element if subscription's notificationOption is “Pull”.

●  Attribute subscription – References the SubscriptionType instance for which this is a Notification.

This chapter describes the information model that support the definition of registry federations. A registry federation is a set of ebXML RegRep servers that have voluntarily agreed to form a loosely coupled union. Such a federation may be based on common business interests or membership in a  community-of-interest. Registry federations enabled clients to query the content of their member servers using federated queries as if they are a single logical server.

9.1   Federation Configuration

A federation is created by the creation of a FederationType instance. A federation may have any number of registries as well as other federations as its members.

Membership of a registry or federation within a parent federation is established by creating an Association between the RegistryType or FederationType instance representing the registry or federation seeking membership, and the FederationType instance representing the parent federation as follows:

●  The Association MUST have its associationType be the id of the canonical ClassificationNode “HasFederationMember”

●  The Association MUST have as its sourceObject the FederationType instance representing the parent federation

●  The Association MUST have as its targetObject the RegistryType or FederationType instance that is seeking membership within the parent federation as shown in Illustration 10.

 

Thus a Federation is defined by a tree where a FederationType instances are root and intermediate n, RegistryType instances are leaf nodes and HasFederationMember AssociationType instances are the edges between the nodes. This tree is referred to as the federation membership tree.

9.2   RegistryType

Base Type: RegistryObjectType

RegistryType instances are used to represent an ebXML RegRep server. RegistryType instances are also used by a server to advertise the capabilities it supports. A client MAY read the RegistryType instance for a server to determine whether it is compatible with a server or not. Profiles of ebXML RegRep specifications MAY define canonical slots to represents support for the profile as well as optional features defined by the profile.

9.2.1   Syntax

9.2.2   Example

The following example describes an ebXML RegRep server operated by organization with id “urn:acme:Organization:acme-inc”, that implements the “RegistryFull” conformance level of version 4.0 of the ebXML RegRep specifications. The server performs replication synchronization once a day (P1D) and performs cataloging of submitted content immediately when content is submitted.

9.2.3   Description

Node	Type	Cardinality	Default Value	Specified By	Mutable
catalogingLatency	xs:duration	0..1	P1D (once a day)	Server	Yes
conformanceProfile	xs:string	0..1	RegistryLite	Server	Yes
operator	objectReferenceType	1		Server	Yes
replicationSyncLatency	xs:duration	0..1	PT0S (immediately)	Server	Yes
specificationversion	objectReferenceType	1		Server	Yes

 

●  Attribute catalogingLatency - A RegistryType instance MAY have an attribute named catalogingLatency that specifies the maximum latency between the time a submission is made to the server and the time it gets cataloged by any cataloging services defined for the objects within the submission. The default value of PT0S indicates a duration of 0 seconds which implies that cataloging happens immediately when request is submitted.

●  Attribute conformanceProfile - A RegistryType instance MAY have an attribute named conformanceProfile that declares the conformance profile that the server supports. The conformance profiles choices are “RegistryLite” and “RegistryFull” as defined by [regrep-rs-v4.0].

●  Attribute operator - A RegistryType instance MUST have an attribute named operator that is a reference to the Organization instance representing the organization for the server’s operator. Since the same Organization MAY operate multiple registries, it is possible that the home registry for the Organization referenced by operator may not be the local registry.

●  Attribute replicationSyncLatency - A RegistryType instance MAY have an attribute named replicationSyncLatency that specifies the maximum latency between the time when an original object changes and the time when its replica object within the local server gets updated to synchronize with the new state of the original object. The default value of P1D indicates a duration of once a day.

●  Attribute specificationVersion - A RegistryType instance MUST have an attribute named specificationVersion that is the version of the ebXML RegReg Specifications it implements.

9.3   FederationType

Base Type: RegistryObjectType

Federation instances are used to represent a registry federation. A FederationType instance has a set of RegistryType instances as its members. The membership of a RegistryType instance in a federationType instance is represented by an AssociationType instance whose type is HasFederationMember.

9.3.1   Syntax

9.3.2   Example

The following example shows a Federation with two independently-operated ebXML RegRep servers as members.

9.3.3   Description

Node	Type	Cardinality	Default Value	Specified By	Mutable
replicationSyncLatency	xs:duration	0..1	P1D    (1 day)	Client	Yes

 

●  Attribute replicationSyncLatency - A FederationType instance MAY specify a replicationSyncLatency attribute that describes the time duration that is the amount of time within which a member of this Federation MUST synchronize itself with the current state of the Federation. Members of the Federation MAY use this parameter to periodically synchronize the federation metadata they MUST cache locally about the state of the Federation and its members. Such synchronization MAY be based upon the registry event notification capability.

 

This chapter defines the Information Model used to control access to RegistryObjects and RepositoryItems managed by it. It also defines a normative profile of [XACML] for ebXML RegRep.

It is assumed that the reader is already familiar with [XACML]. This specification does not provide any introduction to [XACML].

A server MUST support the roles of both Enforcement Point (PEP) and a Policy Decision Point (PDP) as defined in [XACML].

The Access Control Model attempts to reuse terms defined by [XACML] wherever possible. The definitions of some key terms are duplicated here from [XACML] for convenience of the reader:

 

Term	Description
Access	Performing an action. An example is a user performing a delete action on a RegistryObject.
Access Control	Controlling access in accordance with a policy. An example is preventing a user from performing a delete action on a RegistryObject that is not owned by that user.
Action	An operation on a resource. An example is the delete action on a RegistryObject.
Attribute	Characteristic of a subject, resource, action. Some examples are: • id attribute of a subject • role attribute of a subject • group attribute of a subject • id attribute of a RegistryObject resource
Policy	A set of rules. May be a component of a policy set
PolicySet	A set of policies, other policy sets. May be a component of another policy set
Resource	Data, service or system component. Examples are: • A RegistryObject resource • A RepositoryItem resource
Subject	An actor whose attributes may be referenced by within a Policy definition. Examples of subject include: • The registered user associated with a client request • An ebXML RegRep server • A software service or agent

 

10.1   Defining an Access Control Policy

A RegistryObjectType instance is associated with exactly one Access Control Policy that governs “who” is authorized to perform “what” action on that RegistryObject. This Access Control Policy is expressed as an [XACML] document which is the repositoryItem for an ExtrinsicObjectType instance. The Access Control Policy is published to the server as an ExtrinsicObject and repositoryItem pair using the Submit protocol defined by [regrep-rs-v4.0].

The objectType attribute of this ExtrinsicObject MUST reference a descendent of the “XACML” ClassificationNode (e.g. “Policy” or PolicySet”) in the canonical ObjectType ClassificationScheme.

10.2   Assigning Access Control Policy to a RegistryObject

An Access Control Policy MAY be assigned to a RegistryObjectType instance using the canonical slot  “urn:oasis:names:tc:ebxml-regrep:rim:RegistryObject:accessControlPolicy”. The value slot references the ExtrinsicObject representing the Access Control Policy and contains the id of that ExtrinsicObject.

If a RegistryObjectType instance does not have an Access Control Policy explicitly associated with it via the canonical slot with name “urn:oasis:names:tc:ebxml-regrep:rim:RegistryObject:accessControlPolicy”, then it is implicitly associated with the default Access Control Policy defined for the server.

 

 

Illustration 11 shows a UML instance diagram where an Organization instance org references an ExtrinsicObject instance accessControlPolicy as its Access Control Policy object using the canonical accessControlPolicy slot.

10.2.1        Default Access Control Policy for a RegistryObject

A server MUST support a default Access Control Policy. A server MAY implement any default access control policy. The default Access Control Policy applies to all RegistryObjectType instances that do not explicitly have an Access Control Policy assigned.

This following specify the semantics of a suggested default Access Control Policy that a server SHOULD implement:

●An unauthenticated client is permitted to perform read actions (that do not modify the state of resources) on any resource

●An authenticated client with authentication credentials of a registered user is permitted all actions on RegistryObjects submitted by the user

●A authenticated client with authentication credentials that are assigned the canonical subject role of "urn:oasis:names:tc:ebxml-regrep:SubjectRole:RegistryAdministrator" is permitted to perform any action on any object

10.2.2        Access Control Policy Inheritance

A RegistryObjectType instance that does not explicit define an Access Control Policy MAY inherit an  Access Control Policy from its nearest RegistryPackageType ancestor if it is in the membership hierarchy of a RegistryPackageType instance.

An Access Control Policy for members of a RegistryPackageType instance MAY be assigned to the RegistryPackageType instance using the canonical slot “urn:oasis:names:tc:ebxml-regrep:rim:RegistryPackage:memberAccessControlPolicy”. The value slot references the ExtrinsicObject representing the Access Control Policy and contains the id of that ExtrinsicObject. The member Access Control Policy is implicitly inherited as the applicable Access Control Policy for any member RegistryObjectType instance that does not have an explicit Access Control Policy assigned to it.

In the event that a RegistryObjectType instance has a member Access Control Policy defined from two  RegistryPackageType ancestors at the same ancestry level a server MAY choose any mechanism to select one of the two  member Access Control Policies.

Algorithm for Getting Applicable Access Control Policy

A server MUST implement the following algorithm for determining the applicable Access Control Policy for a RegistryObjectType instance:

●  If an Access Control Policy is explicitly assigned to the object then use it

●  If no Access Control Policy is explicitly assigned to the object then get the member Access Control Policy from a nearest RegistryPackageType ancestor of the object

●  If no Access Control Policy is explicitly assigned to the object  or inherited from a RegistryPackageType ancestor of the object then use the system-wide default Access Control Policy

10.2.3        Performance Implications

Excessive use of custom Access Control Policies MAY result in slower processing of registry requests in some registry implementations. It is therefor suggested that, whenever possible, a submitter SHOULD reuse an existing Access Control Policy. Submitters SHOULD use good judgment on when to reuse or extend an existing Access Control Policy and when to create a new one.

 

10.3   Defining a Contextual Role

A contextual role may be define by a RoleType instance within a server as defined next.

10.3.1        RoleType

Base Type: RegistryObjectType

Syntax

10.3.2        Example

The following examples shows a RoleType instances representing a contextual role of “ProjectLead” within the organizational context of an Organization TestSubmittingOrg1.

10.3.3        Description

Node	Type	Cardinality	Default Value	Specified By	Mutable
type	objectReferenceType	1		Client	Yes

 

●  Attribute type - Each RoleType instance MUST have a type attribute that identifies the type of role.

○  The value of the type attribute SHOULD be a reference to a ClassificationNode within the canonical SubjectRole ClassificationScheme. 

○  A server MUST support the canonical subject role types as defined by the canonical SubjectRole ClassificationScheme. Deployments and profiles may extend the canonical SubjectRole ClassificationScheme by adding additional ClassificationNodes to it.

●  The RoleType instance may have any number of Slots that provide context for the role as a name/value pair. The name attribute of each such context slot provides the context key while the value of the Slot (typically a string) provides the context value

10.4   Assigning a Contextual Role to a Subject

A subject such as a registered user MAY be assigned a contextual role by associating the id attribute value of the RoleType instance representing the contextual role with the id of the subject. This specification does not define how such an association is made. Implementations may provide this association in an implementation specific manner. For example, in an LDAP based identity management system this may be done by making the node representing the subject to be a member of a groupOfName node as illustrated below:

10.5   Action Matching

An XACML Access Control Policy MAY use an action identifier associated with the action as an action attribute within <xacml:ActionMatch> elements to match the action that is authorized for a subject on a resource.

The following requirements are defined for a server for action matching:

●A server MUST specify the action identifier in the request context for an  XACML  decision request using a <xacmlc:Request>/<xacmlc:Action>/<xacmlc:Attribute> element

○  The <xacmlc:Attribute> element MUST have an AttributeId attribute with content  "urn:oasis:names:tc:xacml:1.0:action:action-id"

○  The <xacmlc:Attribute> element MUST have a DataType attribute with value “http://www.w3.org/2001/XMLSchema#string”

○  The <xacmlc:Attribute> MUST have a <xacmlc:AttributeValue> element  whose content MUST be the id attribute of the ClassificationNodeType instance within the canonical ActionTypeScheme that represent the requested action

●The following requirements are defined for an Access Control Policy for action matching:

●The policy MAY match an action using an <xacmlp:ActionMatch> element

●The <xacmlp:ActionMatch> element MUST have a <xacmlp:AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string"> element whose content MUST be the id attribute of a ClassificationNodeType instance within the canonical ActionTypeScheme

●The <xacmlp:ActionMatch> element MUST have a <xacmlp:ActionAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" DataType="http://www.w3.org/2001/XMLSchema#string"/> element

 

The following example shows an Action that matches the “Read” action.

 

10.5.1        Action Attribute: reference-source

This attribute is only relevant to the “Reference” action. This attribute MAY be used to specify the object from which the reference is being made to the resource being protected. The AttributeId of this attribute MUST be “urn:oasis:names:tc:ebxml-regrep:rim:acp:subject:reference-source”. The value of this attribute MUST be the value of the id attribute for the object that is the source of the reference. A server MUST specify this attribute for a reference action.

10.5.2        Action Attribute: reference-source-attribute

This attribute is only relevant to the “Reference” action. This attribute MAY be used to specify the attribute name within the RegistryObjectype that the reference-source object is an instance of. A server MUST specify this attribute for a reference action. The AttributeId of this attribute MUST be “urn:oasis:names:tc:ebxml-regrep:rim:acp:subject: reference-source-attribute”. The value of this attribute MUST be the name of an attribute within the RIM type that is the type for the reference source object.

For example, if the reference source object is an Association instance then the reference-source-attribute MAY be used to specify the values “sourceObject” or “targetObject” to restrict the references to be allowed from only specific attributes of the source object. This enables, for example, a policy to only allow reference to objects under its protection only from the sourceObject attribute of an Association instance.

10.6   Subject Matching

An XACML Access Control Policy MAY use the identity and roles associated with the subject as subject attributes within <xacml:SubjectMatch> elements to match the subject that is authorized for an action on a resource.

The following requirements are defined for a server for subject matching:

●A server MUST specify the subject identifier in the request context for an XACML decision request using a <xacmlc:Request>/<xacmlc:Subject>/<xacmlc:Attribute> element

○  The <xacmlc:Attribute> element MUST have an AttributeId attribute with value  "urn:oasis:names:tc:xacml:1.0:subject:subject-id"

○  The <xacmlc:Attribute> element MUST have a DataType attribute with value “http://www.w3.org/2001/XMLSchema#string”

○  The <xacmlc:Attribute> MUST have a <xacmlc:AttributeValue> element whose content MUST be the unique id associated with the requestor

●A server MUST specify any subject roles in the request context for an XACML decision request using a <xacmlc:Request>/<xacmlc:Subject>/<xacmlc:Attribute> element. This specification does not define how roles are assigned to a subject. Implementations SHOULD provide that functionality in an implementation-specific manner.

○  The <xacmlc:Attribute> element MUST have an AttributeId attribute with value  "urn:oasis:names:tc:ebxml-regrep:3.0:rim:acp:subject:role"

○  The <xacmlc:Attribute> element MUST have a DataType attribute with value “http://www.w3.org/2001/XMLSchema#string”

○  The <xacmlc:Attribute> MUST have a <xacmlc:AttributeValue> element  whose content MUST be the id attribute value of a RoleType instance associated with the requestor

10.6.1        Matching Subjects By Id

The following requirements are defined for an Access Control Policy for subject matching by the subject id:

●The policy MAY match a subject by id using an <xacmlp:SubjectMatch> element

○  The <xacmlp:SubjectMatch> element MUST have a <xacmlp:AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string"> element whose content MUST be the unique id of the subject

○  The <xacmlp:SubjectMatch> element MUST have a <xacmlp:SubjectAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id" DataType="http://www.w3.org/2001/XMLSchema#string"/> element

 

The following example shows a Subject that matches a registered user with id “urn:acme:person:Danyal”:

 

10.6.2        Matching Subject By Role

The following requirements are defined for an Access Control Policy for subject matching by a subject role:

●The policy MAY match a subject by a contextual role using an <xacmlp:Condition> element

○  The <xacmlp:Condition> element MUST use an <xacmlp:Apply/@FunctionId='urn:oasis:names:tc:ebxml-regrep:4.0:rim:acp:function:matches-role'> element to invoke the “matches-role” XACML function as defined by this specification

 

The following example shows a Subject that matches a subject role “ProjectLead” within the organizational context of Organization TestSubmittingOrg1 and register context of Register TestRegister1:

 

10.7   Resource Matching

An XACML Access Control Policy MAY use the id associated with the resource as resource attributes within <xacml:ResourceMatch> elements to match a resource within an authorization decision for an action on the resource.

The following requirements are defined for a server for resource matching:

●A server MUST specify the resource identifier in the request context for an XACML decision request using a <xacmlc:Request>/<xacmlc:Resource>/<xacmlc:Attribute> elementThe <xacmlc:Attribute> element MUST have an AttributeId attribute with value  "urn:oasis:names:tc:xacml:1.0:resource:resource-id"

○  The <xacmlc:Attribute> element MUST have a DataType attribute with value “http://www.w3.org/2001/XMLSchema#string”

○  The <xacmlc:Attribute> MUST have a <xacmlc:AttributeValue> element  whose content MUST be the unique id associated with the resource

●A server MUST specify the owner attribute value of the RegistryObjectType resource in the request context for an XACML decision request using a <xacmlc:Request>/<xacmlc:Resource>/<xacmlc:Attribute> element

○  The <xacmlc:Attribute> element MUST have an AttributeId attribute with value  "urn:oasis:names:tc:ebxml-regrep:3.0:rim:acp:resource:owner"

○  The <xacmlc:Attribute> element MUST have a DataType attribute with value “http://www.w3.org/2001/XMLSchema#string”

○  The <xacmlc:Attribute> MUST have a <xacmlc:AttributeValue> element whose content MUST be the owner attribute value of the RegistryObjectType resource

 

10.7.1        Matching a Resource By Id

The following requirements are defined for an Access Control Policy for resource matching by the resource's id:

●The policy MAY match a resource by id using an <xacmlp:ResourceMatch> element

○  The <xacmlp:ResourceMatch> element MUST have a <xacmlp:AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string"> element whose content MUST be the unique id of the resource

○  The <xacmlp:ResourceMatch> element MUST have a <xacmlp:ResourceAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" DataType="http://www.w3.org/2001/XMLSchema#string"/> element

 

The following example shows a ResourceMatch that matches a resource with id “urn:acme:person:Danyal”:

10.7.2        Matching a Resource Using XPATH Expression

An XACML Access Control Policy MAY use any node in the XML document representing a RegistryObjectType instance within an <xacml:ResourceMatch> element. In this case, the <xacml:ResourceMatch> element SHOULD use an XPATH expression to match any part of the XML element representing the RegistryObjectType instance.

The following example uses XPATH expression to match resource if it has a Slot with name “someSlotName”.

 

10.8   Canonical XACML Functions

Section A.3 of [XACML] defines a set of standard functions. This section defines addition XACML functions that MUST be supported by an ebXML RegRep server that supports XACML based custom access control policies. XACML specifies the following functions. If an argument of one of these functions were to evaluate to "Indeterminate", then the function MUST be set to "Indeterminate".

10.8.1        Function AssociationExists

Function ID: urn:oasis:names:tc:ebxml-regrep:rim:acp:function:AssociationExists

 

Parameter / Return	Name	Description	Data Type
Parameter 1	sourceObject	Specifies a value for the sourceObject attribute of AssociationType. MAY use '%' and '_' as wildcard to match multiple or single characters.	http://www.w3.org/2001/XMLSchema#string
Paremeter 2	targetObject	Specifies a value for the targetObject attribute of AssociationType. MAY use '%' and '_' as wildcard to match multiple or single characters.	http://www.w3.org/2001/XMLSchema#string
Parameter 3	type	Specifies the path attribute value for a ClassificationNode in the AssociationType ClassificationScheme. MAY use '%' and '_' as wildcard to match multiple or single characters. This attribute is used to match the type attribute of AssociationType. The type parameter MUST also match ClassificationNodes that are descendants of ClassificationNode specified by the  type parameter. This parameter is optional and MAY be omitted.	http://www.w3.org/2001/XMLSchema#string
Returns		MUST return “True” if and only if an AssociationType instance exists that matches the specified sourceObjectId, targetObjectId and type. MUST return “False” otherwise.	http://www.w3.org/2001/XMLSchema#boolean

 

10.8.2        Function ClassificationNodeCompare

Function ID: urn:oasis:names:tc:ebxml-regrep:rim:acp:function:ClassificationNodeCompare

A client MAY use this XACML function to test whether a resource's objectType attribute matches a specific objectType or its sub-types.

 

Parameter / Return	Name	Description	Data Type
Parameter 1	node1	Specifies the id of a ClassificationNode.	http://www.w3.org/2001/XMLSchema#string
Paremeter 2	node2	Specifies the id of a ClassificationNode.	http://www.w3.org/2001/XMLSchema#string
Returns		MUST return “True” if and only if ClassificationNode with id matching node2 value is same as or descendent of  if ClassificationNode with id matching node1. MUST return “False” otherwise.	http://www.w3.org/2001/XMLSchema#boolean

 

10.8.3        Function matches-role

Function ID: urn:oasis:names:tc:ebxml-regrep:4.0:rim:acp:function:matches-role

 

Parameter / Return	Name	Description	Data Type
Parameter 1	roles	Specifies a bag containing ids of RoleType instances representing the contextual roles that a subject is expected to have	Bag of attributes of type http://www.w3.org/2001/XMLSchema#string
Paremeter 2	roleType	Specifies the id of a ClassificationNode within the canonical SubjectRole ClassificationScheme	http://www.w3.org/2001/XMLSchema#string
Subsequent parameters MUST come in pairs where each pair specifies a context key/value pair. Any number of such pairs MUST be supported by server implementing this function
Parameter 3+N	contextKey	Specifies a context identifier	http://www.w3.org/2001/XMLSchema#string
4+N	contextValue	Specifies a context value associated with the context identifier specified by previous parameter	http://www.w3.org/2001/XMLSchema#string
Returns		MUST return “True” if and only if at least one RoleType instance assigned to the subject meets the following conditions: •  If roleType is specified, then the type attribute of the RoleType instance MUST match the role type ClassificationNode (or a descendant of it) specified by the roleType parameter •  If any context key/value pairs are specified then the RoleType instance MUST have a Slot whose name matches the context key and whose value matches the context value MUST return “False” otherwise.	http://www.w3.org/2001/XMLSchema#boolean

 

10.9   Constraints on XACML Binding

This specification normatively defines the following constraints on the binding of the Access Control Model to [XACML]. These constraints MAY be relaxed in future versions of this specification.

●    All Policy and PolicySet definitions MUST reside within an ebXML Registry as RepositoryItems.

 

10.10       Resolving Policy References

An XACML PolicySet MAY reference XACML Policy objects defined outside the repository item containing the XACML PolicySet. A server implementation MUST be able to resolve such references. To resolve such references efficiently a server SHOULD be able to find the repository item containing the referenced Policy without having to load and search all Access Control Policies in the repository. This section describes the normative behavior that enables a server to resolve policy references efficiently.

A server SHOULD define a Content Cataloging Service for the canonical XACML PolicySet objectType. The PolicySet cataloging service MUST automatically catalog every PolicySet upon submission to contain a special Slot with name ComposedPolicies. The value of this Slot MUST be a Set where each element in the Set is the id for a Policy object that is composed within the PolicySet.

Thus a server is able to use an ad hoc query to find the repositoryItem representing an XACML PolicySet that contains the Policy that is being referenced by another PolicySet.