Page Comparison

...

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.

See Also

• Anchor
  specFramework specFramework

  OSID Specification Framework

• Anchor
  languagePrimitives languagePrimitives

   List of Language Primitives

• Anchor
  primitives primitives

   List of All Primitives
• OSID Java Binding Primitive Transformations

• Anchor
  osid.OsidPrimitive osid.OsidPrimitive

   osidosid.OsidPrimitive