Add very basic Playground to harden contexts.

[BigBlueHat]

The playground is build with petite-vue with the parser bundled via
esbuild index.ts --format=esm --bundle --outfile=docs/bundle.js

The docs/ folder is intended to be hosted via GitHub Pages.

Here's a demo hosted via GitHub Pages on my fork: https://bigbluehat.github.io/jsonld-context-parser.js/

Relates to w3c/json-ld-bp#19

[BigBlueHat]

@rubensworks I wrote this because I'm finding many projects use a very high number of CURIEs in their context files (presumably primarily for the typing convenience). I found this library extremely helpful to quickly "harden" a context to use full URLs and thereby avoid the "risk" of CURIEs being used in the content.

The risk being that the term space remains wide open, so people using a context that uses them have the "freedom" to mint their own terms beyond what was expected/intended by the context.

This may not be of concern in many scenarios (like the SEO use case where "failing" isn't fatal), but it is a concern in environments where constrained contents are a deliberate design feature--such as Verifiable Credentials, API extensions (ex: ActivityPub), and Web of Things.

Essentially anywhere one might want to use the @protected keyword can benefit from this library, CLI, and now Playground. 😸

Thanks again for building this library!

Cheers,
🎩

[rubensworks]

Thanks @BigBlueHat, this is very useful!

Would you be open to tweaking the PR so it builds the bundle in a GH workflow and deploys to GH pages?
That way, the bundle.js and out.js won't have to be included in the repo anymore, to reduce repo size.

[BigBlueHat]

Would you be open to tweaking the PR so it builds the bundle in a GH workflow and deploys to GH pages?

Are you OK if they continue to use the docs/ folder? Or do you want a separate branch?

[rubensworks]

Sure, docs in the master branch for the source files makes sense.
The GH action could then build and deploy the bundled files to a gh-pages branch.