add support for `document.location` resolver plugins

[keighrim]

New Feature Summary

Currently document.location values in MMIF have to be URI/IRI format, but the SDK only support file path resolution for the file protocol (which holds already resolved to a local path anyway).
As resolution logic can be very different for different URI scheme, I'd like to add "plugin"-based** support for additional local URI handlers.

Related

This was first suggested in #206 (comment) .
Also as we're building a data housing solution for Brandeis internal servers, the first scheme to add will probably a client for that datahouse.

Alternatives

Alternatively, we can add additional handlers as part of mmif-python distribution. It is obvious that the entire development-package-delivery workflow would become much simpler is that way. However here are some possible issue with such a monolithic approach.

• when there's an update in one URI handler module, we need to release a new version of mmif-python.
• when an external developer wants to develop a URI handler for their own data pipeline, they will have to fork the mmif-python

Additional context

** by plugins, I mean separate python packages that are NOT shipped within the mmif-python PyPI distribution. Plugins must have a common affix in the package names so that the core library (in our case, mmif.serialize module that holds the Document class and document.location retrieval methods) can load at initiation time.

[marcverhagen]

We could have the basics in the SDK (file, http, ftp) and any specific additions as plugins. I was thinking of some utilities package as a spot for the plugins, but separate plugins may work as well, although I don't see how the load-at-initiation would work for external packages.

[keighrim]

Yeah, in the linked draft PR (345dc03) , I added primitive implementation of plugin discovery logic using mmif_docloc_ as the common prefix. The idea is taken from https://packaging.python.org/en/latest/guides/creating-and-discovering-plugins/ but we can explorer other implementations for the plugin ecosystem.

[marcverhagen]

Ah, I did not notice the linked PS. That would work well, I like it.