v0.1.8

What's new

Every xAPI statement names the build it came from

For compliance and audit trails, xapi and finished statements now carry two standard xAPI fields:

"context": {
  "revision": "sha256:…",
  "platform": "h5p-offline-player 0.1.8"
}

• revision identifies the exact build of the package. It is a SHA-256 of the archive's index (every file's name, size and checksum): any change to the package gives a new value, and replaying the same file gives the same one.
• Library bundles: when libraries supplied them (the hub or a bundle URL), the bundle's fingerprint follows: sha256:…; libraries sha256:….
• Your own values stay: a revision or platform the content sets itself is never overwritten.
• player.revision (new, read-only) returns the same value once the package is indexed.

The revision identifies a build; it isn't a forgery-proof seal. Keep the published .h5p, and anyone can recompute it. When a build was current belongs in your own version record (your LMS, LRS or document control). An audit compares each statement's revision and timestamp against that record. For a major change, publish at a new URL, which also gives the content a new xAPI activity ID.

Holding and releasing statements

On a host without Range support, content can start playing before the download finishes, when the revision isn't known yet. Statements sent in that window are held and released in order, with their revision, once it's known. If the page is hidden first (the tab closes, or a phone hides it), they're released immediately without it, so a learner's record is never lost.

Upgrading

Nothing breaks: no attributes or events changed.

• With a bundler: update the package.

• Without a build step: if you serve h5p-sw.js yourself, copy the new one as well. An older worker doesn't compute the revision; statements then carry platform only.

  npm i @missing-elements/h5p-offline-player@0.1.8

Full changelog: v0.1.7...v0.1.8