should we have a `contextLoader` option, distinct from the `documentLoader`?

Currently, the JsonLdOptions has a single loader configured, called documentLoader, which is used for two different purposes:

• load the JSON-LD documents to be processed
• load the contexts, when referenced by IRIs, that those documents contain

It is generally agreed that fetching arbitrary contexts from the Web is often not a good idea (as pointed out in the security and privacy considerations of JSON-LD), but this often overlooked by newcomers or even implementers.

I would argue that the conflation of the document loader and the context loader contributes to this, and that separating them in JsonLdOptions could help get the message through. In particular, it would be specified that

• the default document loader fetches any IRI from the web
• the default context loader does not fetch anything from the web, but may have cached version of some well-known contexts

Start with the JsonLdOptions definition in the JSON-LD API specification and review the linked security and privacy considerations. Determine how separate documentLoader and contextLoader options should be specified, including their defaults and handling of well-known cached contexts. Done means the API behavior and security expectations are unambiguous.