...
Concepts like classes and objects disappear. Others like parameter and primitive have a narrower connotation than what a Java developer would be accustomed. And the definition of "osid" gets fuzzier.
Terminology Issues
These are a list of terms that often get tossed around. Mixing terminology across frameworks will always cause confusion. When a term is in direct conflict with the OSID Specification or its few basic concepts, it's a good idea to lose it and adapt. This can be difficult when trying to learn something by comparing it to another thing you already know.
Others terms are more conceptual in nature and we tend to use them informally.
terminology compatible with OSIDs
shaky terminology
terminology incompatible with the OSIDs
Attributes & Data Fields
...
An OSID Provider may likely employ data objects to satisfy the contract of an OsidObject. An OSID Consumer sees this through the window of the interface. The OSID Consumer may do whatever it likes with this information, including referring to them as simple data elements. However it can be an impediment when trying to understand the nature and applications of these interfaces whose implementation may require an underlying OSID Provider rather than a pull from a database table, for example.
Boundary
Boundary
Boundary can be a cool word but is a bit slippery. In the OSIDs, it may also refer the line between an OSID Consumer and an OSID Provider, i.e. "The details of the Asset are opaque through the OSID boundary."
Many listeners will assume it means the scope of a service, i.e. "There's a service boundary between authentication and authorization." However, jumping laterally between two OSIDs also implies a vertical movement between an OSID Provider. This interpretation would not be wrong but it may fail to clarify exactly what is meant.
Contract
The term contract is often used in service designs to distinguish an interface from a message structure or DTO. The message structure and DTO are considered data while the contract defines the operations on that data. OSIDs define the contractual agreement between service consumers and service providers. In the OSID world, most everything in the specification can be is considered a contract. This term doesn't help qualify anything here but is often used to emphasize the nature of the interface., i.e. "The AgentList is a contract."
DTO
A Data Transfer Object is used to transfer bags of data through system layers. However, OSIDs are just piles of method signatures organized in interfaces.
...