OKI publishes OSIDs, which are not quite like typical specifications. The OSIDs are a kind of conceptual API, which can be expressed in different programming languages. The bindings to these languages are interfaces (or the nearest thing to that concept that the language has). The interfaces require implementations by service providers, which are separate releases by vendors or other contributors.

In V2 (the current version) of OKI a lowest-common-denominator Java language binding acted as both language-specific binding and specification for the OSIDs. As new languages are being added, an XML expression of the "conceptual API" has been released (XOSIDs, available on Sourceforge), along with XSLT for transformation into language-specific bindings. This is the approach that is being followed for V3 of the OSIDs. Both the XML-based specification and the language-specific bindings will be part of the revision process for V3.

See: OSID V3 section of this site for the latest developments

What OKI calls "Types" are crucial to the interoperability of the OSIDs. The OSIDs themselves are written very generically. It is only through a common understanding of the out-of-band "Types" that applications can make use of the most important functionality. For example, the seach methods in the Repository OSID require a Search Type. It is only by defining a commonly understood set of Search Types that different repositories can be searched in the same way.

The Types themselves are not part of the OKI specification per se; they are expected to be developed by the community as implementations are created. Implementors of OSIDs are strongly encouraged to submit their Types to the community at large.

See OSID V3 Type Package ? for latest on developments

Although the OSIDs represent an approach to a Service-Oriented Architecture (SOA), it is different from the more protocol-oriented approaches and has some new concepts to offer. A good place to begin is in our Library, with The Conceptual Architectural Framework.

The OSIDs are continually evolving and was designed to do so. For insight into the thinking behind how this work, see The Architectural Process.