OsidPrimitives

Summary

OsidPrimitives are interfaces to unmanaged complex elements used throughout the OSIDs. OsidPrimitives are used to describe measurements or to enhance programming language primitives.

Primitives

There are two flavors of primitives in the OSIDs:

language primitives: These are the basic elements assumed to be found in programming languages. Allowed language primitives are defined in the OSID Specification Framework and include boolean, byte, cardinal, decimal, integer, object, string, and timestamp. These are referenced in the OSIDs without further definition and are bound to a language in an OSID Binder.
OsidPrimitives: These primitives are interfaces defined in the OSIDs. Interfaces classified as OsidPrimitives are tagged with the osid.OsidPrimitive interface.

A list of language and OsidPrimitives is in the osid.Syntax enumeration.

Definitions

All OsidPrimitives belong to a service definition. They will be found in their related OSID packages.

Specification Behavior

Interfaces are directional through the OSIDs. Most interfaces are owned by the OSID Provider. This means the OSID Provider has knowledge of the interface implementation but such knowledge is completely encapsulated from OSID Consumers. OsidReceiver interfaces work the other way. OsidReceivers are used for callbacks and owned by an OSID Consumer but are completely encapsulated from OSID Providers (one can argue that the OSID Consumer and OSID Provider roles are reversed in this case).

OsidPrimitives are not owned by either OSID Consumers or OSID Providers. Either party may have knowledge of their implementations but cannot assume anything about the implementation of the OsidPrimitives they receive. Each party must respect the OsidPrimitives given to them.

OsidPrimitives vs. OsidObjects

OsidObjects are Identifiable entities. Only the provider of an OsidObject may assign the Id of an OsidObject. This concept extends to non-OsidObject Identifiables where it is the provider, which in rare cases may be the application end of the stack, that is responsible for the underlying object and thus its Id. OsidObjects belong to OSID Providers. Two OsidObjects are the same if their Ids are the same even if the observed data differs.

OsidPrimitives are not owned by either an OSID Consumer nor an OSID Provider. Either party may construct them and pass them to the other side. They are independent.

OsidPrimitives behave much like language primitives in this respect. An integer is just a number. We don't concern ourselves with its implementation even if in some languages it were possible to inject different implementations of an integer object. All hell will break loose if there was an incompatibility. OsidPrimitives are an inherent agreement among OSID Consumers and OSID Providers.

OsidPrimitives are atomic and we don't think about it in terms of its component parts. Some primitives are more complex. Java's BigDecimal is also just a number. It has a value, scale, and various calculation methods. However, BigDecimals are not persisted as a set of "fields" stored in its own relation. Although OsidPrimitives are also defined using interface definitions, they are not entities. Their uniqueness depends on their values.

OsidPrimitives need to be transportable and persistable as a unit. The formats are not specified and there may be many different schemes for different situations. Serialization of OsidPrimitives for web transport may have to take into account escaping certain characters. The party responsible for the serialization is the party that ultimately needs to understand the implementation of the OsidPrimitive. When the OsidPrimitives originates from an unknown source, it often needs to be wrapped or converted into something whose serialization behavior is well understood.

OsidPrimitives require special handling from any of the other object-ish interfaces.

osid