Preparing for New Bin Names and Asset Types

The OLSA Search-and-Learn® functions return search results in the following format:

<searchResults …>

  <bin biname=”xyz1” …>

    <asset type=”t1”…/>

    <asset type=”t2”…/>

    <asset type=”t1”…/>

        … more asset hits…

  </bin>

  <bin biname=”xyz2” …>

       … more asset hits …

  </bin>

       … more bins …

</searchResults>

Depending on the search function and search criteria that is used, one or more bins will be returned. Within a bin, zero or more asset hits will be returned.

The name of a bin is designated with the binname attribute. This value is not a printable or end-user-friendly value.

The type of an asset is designated with the type attribute. This value is not a printable or end-user-friendly value.

As the OLSA product evolves, SkillSoft will introduce new bin names and asset types.

The vendor-application should avoid implementations that hard-code checks for a specific bin name or asset type. The vendor-application should write implementations that will accommodate the introduction of new bin names and asset types. At a minimum, the vendor-application should not break if new bin names or asset types are introduced.

A particular bin name or asset type may not always appear in a search result as well. What appears in the search result is dependent on the end user’s assignment setup in OLSA. Typically, this translates to the complete entitlement purchased by the Customer from SkillSoft but it does not always the case. Vendor-application implementations should accommodate this as well.

At the moment the vendor-application has the following approaches for organizing search results:

• Ignore the bin structure and render all asset hits in one flat list
• Render all non-empty bins, but group asset hits by bins
• Render specific non-empty bins, group asset hits by bins or not. This has the drawback of missing out on new bins that SkillSoft may introduce.

In all the above, the vendor-application can choose to filter out asset hits that are already managed by a native search engine. This should be by using the nativeid value associated with a given asset hit.

The vendor-application should not need to select or filter out asset hits by type. Doing so might have the drawback of missing out on new asset types introduced by SkillSoft.

The assetid attribute and tag in a search result is a OLSA Search asset id. Not to be confused with an OLSA Asset Integration asset id. An OLSA Asset Integration asset id is specified in the nativeid value of a given search result asset hit.