This page describes the proposal for RegRep 4 Slot improvements.

Issues In RegRep 3

Slots in RegRep3 have the following issues:

Requirements for RegRep 4

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

Issues

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:

Issues:

  <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:

Slots on Embedded Classes - Proposed Solution (Need Review)

 <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:

  1. Attribute Definition - Define an XML structure for defining an expected Slot. This includes all required information for defining the Slot
  2. Attribute Definition Binding - Bind the AttributeDefinition to the ClassificationNode within the ObjectType scheme which represents the domain object type

  3. 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.

  1. Define ObjectType as a sub-type of ClassificationNodeType. Add ParameterType as sub-elements of the extended type

  2. 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

  3. 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:

documents/plan/regrep4/slots (last edited 2009-08-12 18:05:09 by localhost)