The standard SEDRIS function calls, as well as critical data structures, are discussed in detail in Part 4, Volume 17 SEDRIS Reference Manual.

The primary data structures of the SEDRIS API are given below. They are opaque - that is, the details of their implementation are hidden by the API implementation. At a minimum, all SEDRIS users, whether data providers or consumers, need to be familiar with SE_Transmittal and SE_Object. Data consumers, in addition, need to know how to use SE_Iterator, SE_Store, and SE_Search_Filter. SE_Search_Boundary, while also a tool for data consumption, is a somewhat more advanced feature. SE_Packed_Hierarchy is a powerful tool that requires an understanding of objects and their relationships as a prerequisite.

• SE_Iterator

  Given an SE_Object as a starting point, an iterator is a mechanism used to retrieve other objects that are related to the start object. The nature of the relationship is determined by the function used to initialize the iterator, and by the other parameters passed to that function.

• SE_Object

  Represents a handle to a SEDRIS object - that is, a particular instance of a DRM class in a given transmittal.

• SE_Packed_Hierarchy

  A data structure that permits data consumers to retrieve a hierarchy of related objects in a single function call, without the need for individual iterators for each level of the object tree.

• SE_Search_Boundary

  A construct used only during data consumption, which serves as a mechanism allowing the data consumer to limit the scope of a component iterator based on the relationships of the objects considered for retrieval to the boundary.

• SE_Search_Filter

  A construct used only during data consumption, which serves as a mechanism allowing the data consumer to apply the search rules with which the filter was created to various iterators created by the consumer.

• SE_Store

  Represents a handle to a store, which is a construct used to manage memory retrieved from the API by a user. The user shall create a store by calling the SE_CreateStore() function, and is then at liberty to use it for functions that use the store mechanism for memory management.

  The memory managed by a store will remain in scope from the time the user first passes the store to a function that associates the store with some chunk of memory, until the user either passes the store to another such function call (in which case the API disposes of the previous memory being managed by the store) or until the store is freed by the user via a call to SE_FreeStore().

• SE_Transmittal

  Represents a handle to a SEDRIS transmittal.