Properties.

Properties is one of the elements of the OSID Specification (the other two being Type and Context) that often cause debate and confusion. Let's attempt to sort them out and find some peaceful co-existence.

Properties show up in one form or another in three areas of the Specification. One area is the OSID Configuration that is composed of a java.util.Map. This is actually a Configuration object that exists solely within an Implementation instance. The other is in searchCriteria which is often by convention rather than Specification. Finally, there's the org.osid.shared.Properties object (often masking a java.util.Map underneath) that is used in various OSIDs to describe something about an object. We'll ignore the other two vernacular uses and focus on the latter.

The contents of this metadata falls completely outside the current Specification. An Agent in one Implementation may have properties of name and phone while another may have a single property called email. The Application must handle these Properties if it is to perform any useful function above and beyond that of a simple browser and yet there's no guaranteed interoperability if Properties are used. That some OSID Objects like Agent and Asset are little more than containers for their metadata make Property management essential.

Why not use methods? The OSIDs use methods sparingly for managing metadata. The most common are the pervasive getDisplayName() updateDisplayName() pair. Should there be methods like Agent.getBusinessFaxNumber() and Asset.setImageFilmISOSpeed()? Some people argue this would be the only way to concretely add specification around a metadatum. Where one can identify a set of common properties, like displayName, it works. But it can't be assumed all Assets are photographs that were taken with film. Nor it is reasonable to specify every Object in the universe. This is why there are Properties.

One of the controversial decisions in OSID version 2.0 was to make this object metadata be read-only. This was not an oversight but a decision on the part of the designers. Since the Properties have no specification, you can't update them. For example, two Implementations may both use the Property key price, but one expects it in USD and the other Pounds. Unfortunately, however, the same holds true when looking for a specific Property. The only interoperability you can be achieve is by restricting the Application to casually displaying the list of available Properties.

Unless some syntax can be included in these Properties there cannot be any hope for agreement and interoperability. Enter the propertyType that can be used to imply the names and syntax for a set of Properties. The problem with this approach is that it moves the identification problem from the Property element to the propertyType. Also, the mapping between Type and Property is not nearly as simple as understanding a single dimension of Properties (imagine allThePropertiesTheOtherGuyHasExceptForHomePhoneAndTheMetricSystemPropertyType).

Another option is to identify a Property element in a federated way to imply a specific syntax and stay clear of the propertyType.

A Property behaves much like the Java version with a simple key/value scheme. The key is normally a String object where simple identifiers such as "hair color" are stored while the value may be one of "blue", "#2545ff" or "dye no. 9". Instead, some identifier can be stored there that would uniquely identify the Property across Implementations and specify the syntax for the value. For example, when key X is used, it means height in cm. More importantly, two Implementations should use the same key if and only if the same syntax is expected. The key identifier should be a part of a global namespace.

Because the problem sounds so much like what's been encountered before in LDAP and SNMP, object identifiers (OIDs) sound like a good choice to me. Some people like URIs and others may not be interested in joining any common Property scheme and will continue doing what they are doing but there should be some way of telling the difference.

Types have 3 components. A domain, authority and a key. It is an identifier which is what we want in a Property key. This structure includes information as to what identification domain is being used such as OIDs, URIs or some other scheme. The authority can indicate who assigned them although I find this less useful since a key playing in a federated scheme implicitly includes authority information.

Two Implementations making use of the same Property identifier must implement the same definition and syntax. In this way, a common set of Property definitions can be constructed that can be used across Implementations.

For example:

The benefit of using a global identifier is to encourage sharing of common Properties through a common registry to promote interoperability while at the same time allowing for local additions. An LDAP installation may make use of custom attributes while at the same time supporting inetOrgPerson and eduPerson to maximize the number of applications that can use it. This also makes the point that the Property name is an identifier and not a display string that may be interpreted a number of different ways or need to change depending on locale. The definition of the Property is in the syntax and these essentially become specifications unto themselves. Perhaps worth considering as enhancements to the OKI Specification.