This page describes the proposal for RegRep 4 Slot improvements.

Issues In RegRep 3

Slots in RegRep3 have the following issues:

name is not internationalized - P1
Do not allow extensibility and substitution (See OGC wrs.xsd) - P1
Cannot be added to embedded classes (e.g. Email Address) - P2
Values in a multi-valued slot cannot be controlled by specified collections semantic (P3)
- ordered if desired (List semantics)
- unique if desired (Set semantics)
No Slot Definition and Validation - There is no way to restrict a slot to be only allowed on instances of certain objectType, or to require that certain slots be present on instances of certain objectTypes

Requirements for RegRep 4

The following requirements have been identified as high priority for ObjectReference in RegRep 4:

Slots MUST be extensible and substitutable
Must be able to be added to embedded classes
Must be able to be ordered
Slot Definition and Validation - Must be able to be defined on a per objectType basis. Slot definition should allow declaration of datatype, cardinality, optionality, display name and internal attribute name. Must also be able to validate that slots present on an object conform to any restrictions placed in its object definition.

Issues

If a slots ValueList item can be any XML element (including one containing binary data) then this is very powerful. It allows a slot to contain a single or collection value of any type at all. This makes a Slot have certain similarities with ExtrinsicObject that can have any type of RepositoryItem. How to harmonize the two concepts such that it is really simple to associate any type of content as a slot valuelist item

Extensibility - Comitted Solution

The proposed fix is to use type substitution for items of the ValueListType using a ValueType hierarchy.

There will be a non-backward compatible change in XML instance documents as shown in listing below:

#Older Slot syntax from current RIM 3.0
<rim:Slot name="Keywords">
    <rim:ValueList>
        <rim:Value>CIWS</rim:Value>
        <rim:Value>Weather</rim:Value>
        <rim:Value>Convective</rim:Value>
    </rim:ValueList>
</rim:Slot>
#Proposed new Slot syntax for RIM 4.0.
#Change adds extra element <rim:ValueListItem> around <rim:Value> element
#This element supports type substitution based extensibility and requires xsi:type attribute
<rim:Slot name="Keywords">
    <rim:ValueList>
        <rim:ValueListItem xsi:type="rim:StringValueType"><rim:Value>CIWS</rim:Value></rim:ValueListItem>
        <rim:ValueListItem xsi:type="rim:StringValueType"><rim:Value>Weather</rim:Value></rim:ValueListItem>
        <rim:ValueListItem xsi:type="rim:StringValueType"><rim:Value>Convective</rim:Value></rim:ValueListItem>
    </rim:ValueList>
</rim:Slot>
#Following example shows how OtherValueType can be used to hold a GML Envelope for spatial data
<rim:Slot
    name="Spatial"
    dataType="urn:ogc:def:dataType:ISO-19107:GM_Envelope">
    <rim:ValueList>
        <rim:ValueListItem xsi:type="rim:OtherValueType">
          <gml:Envelope srsName="urn:ogc:def:crs:OGC:2:WGS84">
            <gml:lowerCorner>-122.35417417669667 19.315255465858254</gml:lowerCorner>
            <gml:upperCorner>-61.80812620735422 48.9307497413461</gml:upperCorner>
          </gml:Envelope>
        </rim:ValueListItem>
    </rim:ValueList>
</rim:Slot>

The schema in rim.xsd for Slot is proposed to be as follows. Things to note are:

The type attribute has been renamed dataType
A collectionType attribute has been added to specifu optional collection semantics
extra element <rim:ValueListItem> around <rim:Value> element
ValueType hierarchy added with StringValueType for preserving semantics of current <rim:Value> and OtherValueType for wrapper for ANY type of value

Issues:

Should Slots have a Name to allow IneternationalStrings

  <complexType name="SlotType">
    <sequence>
      <!--element maxOccurs="1" minOccurs="0" ref="tns:Name"/-->
      <element maxOccurs="1" minOccurs="1" ref="tns:ValueList"/>
    </sequence>
    <attribute name="name" type="tns:LongName" use="required"/>
    <!--slotType value MUST reference a ClassificationNode in the canonical DataType scheme-->
    <attribute name="dataType" type="tns:referenceURI" use="optional"/>
    <!--slotType value MUST reference a ClassificationNode in the canonical CollectionType scheme-->
    <attribute name="collectionType" type="tns:referenceURI" use="optional"/>
  </complexType>
  <element name="Slot" type="tns:SlotType"/>
  <complexType name="ValueListType">
    <sequence>
      <element name="ValueListItem" type="tns:ValueType" minOccurs="0" maxOccurs="unbounded" />
    </sequence>
  </complexType>
  <element name="ValueList" type="tns:ValueListType"/>
  <complexType name="ValueType" abstract="true">
  </complexType>
  <complexType name="StringValueType">
    <complexContent>
      <extension base="tns:ValueType">
        <sequence>
          <element name="Value" type="tns:LongName" minOccurs="0" maxOccurs="1"/>
        </sequence>
      </extension>
    </complexContent>
  </complexType>
  <element name="StringValue" type="tns:StringValueType"/>
  <complexType name="OtherValueType">
    <complexContent>
      <extension base="tns:ValueType">
        <sequence>
          <any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="1" />
        </sequence>
      </extension>
    </complexContent>
  </complexType>
  <element name="OtherValue" type="tns:OtherValueType" />

Internalionalized Slot Name - Proposed Solution

Leave current name attribute as is. It really should be renamed to id but that would be painful incompatibility. Add a new sub-element with cardinality of (0..1) called Name of type InternationalString. Issue:

Is it confusing to have attribute with name "name" and sub-element with name "Name"?
If so how to fix
- Rename name attribute to "id"?
- Use "Label" for name of sub-element?

Slots on Embedded Classes - Proposed Solution (Need Review)

Just add Slots to these classes as shown below:

 <complexType name="EmailAddressType">
    <sequence>
      <element maxOccurs="unbounded" minOccurs="0" ref="tns:Slot"/>
    </sequence>
    ...
  </complexType>

Collection Semantic on Slots - Committed Solution

Add a collectionType attribute on SlotType which has a string value within the CollectionType scheme. The canonical values are: Set, List, Bag. May be extended by deployments.

Slot Definition and Validation- Proposed Solution

The summary of the proposal is as follows:

Attribute Definition - Define an XML structure for defining an expected Slot. This includes all required information for defining the Slot
Attribute Definition Binding - Bind the AttributeDefinition to the ClassificationNode within the ObjectType scheme which represents the domain object type
Attribute Usage Validation - Validate that a published object and its slots match all constraints specified within the AttributeDefinitions for the ObjectType Classification node for that object

Attribute Definition:

It is noteworthy that Attribute Definition requires nearly identical information as that needed for Query Parameter Definition. Following our "reuse a few good primitives" principal, we should try an reuse a common XML type for Query Parameter and ObjectType Attribute definition. For the moment lets consider calling the common type ParameterType.

Attribute Definition Binding:

Attribute Definition Binding to ObjectType ClassificationNodes is the trickiest part where we have at leats 3 alternatives noted to consider.

Define ObjectType as a sub-type of ClassificationNodeType. Add ParameterType as sub-elements of the extended type
Use our new Slot extensibility mechanism to define a a ParameterDefValueType which extends ValueType. Use Slot whose values are of type ParameterDefValueType and add to ObjectType instances
Make ParameterType extend RegistryObjectType. Add ParameterType using Associations to existing ObjectType ClassificationNodes.

Among these 3 choices only the 3 avoids defining a new type (there is already a QueryParameterType which would be generalized as ParameterType). However, 1 and 2 have the advantage that ParameterType is embedded within an ObjectType ClassificationNode and is therefor more efficient at run time. Once we decide on which of these 3 options to use we can add more detail to the proposal.

Important new issue: We need to allow profiles and deployments to define AttributeDefinitions on pre-defined RIM types without modifying them. This may be an argument for option 3.Initially Farrukh was favoring (1) while Nikola was favoring (2). Farrukh's concern with (2) was that it may be lead to less obvious instance documents. So lets see a comparison.

For AttributeDefinition Binding option 1 the following instance document example shows how serviceType attribute is defined for ObjectType Service. A Parameter with name "serviceType" is used to define an attribute whose type is a taxonomy element that must be within one of the two taxonomies specified by the domain attribute. Note that the additional attributes defined using addition Parameters.

<rim:ClassificationNode lid="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Service" code="Service" id="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Service">
    <rim:Name>
        <rim:LocalizedString charset="UTF-8" value="Service"/>
    </rim:Name>
    <rim:Description>
        <rim:LocalizedString charset="UTF-8" value="Service.desc"/>
    </rim:Description>
    <rim:Parameter parameterName="serviceType" datatype="taxonomyElement"
        minOccurs="1" maxOccurs="1">
        <rim:Slot name="domain">
            <rim:ValueList>
                <rim:ValueListItem xsi:type="rim:StringValueType">
                    <rim:Value>urn:ogc:def:ebRIM-ClassificationScheme:ISO-19119:2003:Services</rim:Value>
                </rim:ValueListItem>
                <rim:ValueListItem xsi:type="rim:StringValueType">
                    <rim:Value>urn:foo:SomeOtherServiceTaxonomy</rim:Value>
                </rim:ValueListItem>
            </rim:ValueList>
        </rim:Slot>
        <rim:Name>
            <rim:LocalizedString charset="UTF-8" value="Service Type"/>
        </rim:Name>
        <rim:Description>
            <rim:LocalizedString charset="UTF-8" value="The type of service"/>
        </rim:Description>
    </rim:Parameter>
</rim:ClassificationNode>

For AttributeDefinition Binding option 2 the following instance document example shows how serviceType attribute is defined for ObjectType Service. The Slot names "attributeDefs" is used to define an attribute whose type is a taxonomy element that must be within one of the two taxonomies specified by the domain attribute. Note that the same slot could have additional attributes defined using addition Parameters.

<rim:ClassificationNode lid="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Service" code="Service" id="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Service">
    <rim:Slot name="attributeDefs">
        <rim:ValueList>
            <rim:ValueListItem xsi:type="rim:ParameterValueType">
                <rim:Parameter parameterName="serviceType" datatype="taxonomyElement"
                    minOccurs="1" maxOccurs="1">
                    <rim:Slot name="domain">
                        <rim:ValueList>
                            <rim:ValueListItem xsi:type="rim:StringValueType">
                                <rim:Value>urn:ogc:def:ebRIM-ClassificationScheme:ISO-19119:2003:Services</rim:Value>
                            </rim:ValueListItem>
                            <rim:ValueListItem xsi:type="rim:StringValueType">
                                <rim:Value>urn:foo:SomeOtherServiceTaxonomy</rim:Value>
                            </rim:ValueListItem>
                        </rim:ValueList>
                    </rim:Slot>
                    <rim:Name>
                        <rim:LocalizedString charset="UTF-8" value="Service Type"/>
                    </rim:Name>
                    <rim:Description>
                        <rim:LocalizedString charset="UTF-8" value="The type of service"/>
                    </rim:Description>
                </rim:Parameter>
            </rim:ValueListItem>
        </rim:ValueList>
    </rim:Slot>
    <rim:Name>
        <rim:LocalizedString charset="UTF-8" value="Service"/>
    </rim:Name>
    <rim:Description>
        <rim:LocalizedString charset="UTF-8" value="Service.desc"/>
    </rim:Description>
</rim:ClassificationNode>

As you can see the syntax for (2) is a bit more verbose but the guts are fairly similar. (1) has main drawback that a sub-class of ClassificationNode called ObjectTypeDef must be defined which allows Parameter elements within it. In contrast (2) does not require sub-classing ClassificationNode but requires sub-classing ValueType for slots.

Slot Validation:

For Slot validation it is proposed that we reuse our Validation Service feature and define a Validation Service that is called the CanonicalObjectValidationService. We specify a set of rules that this service must enforce such as:

If an AttributeDef is declared as required then make sure it's corresponding slot is present
A slot's datatype matches the datatype of corresponding AttributeDef if any
A slots cardinality matches the cardinality specified in the corresponding AttributeDef if any