Consolidate functions for replacing path placeholder with path location

[ehennestad]

The following functions seem to have some overlap:

in did.document/readjsonfilelocation:

DID-matlab/code/+did/document.m

Line 728 in f424868

function t = readjsonfilelocation(jsonfilelocationstring)

in did.database/get_document_schema

DID-matlab/code/+did/database.m

Line 1051 in f424868

function schemaStruct = get_document_schema(database_obj, schema_filename) %#ok<INUSL>

did.common.utility. replace_didpath

DID-matlab/code/+did/+common/+utility/replace_didpath.m

Line 1 in f424868

function new_path = replace_didpath(path)

Any other places?

Could consolidate this into a set of utility functions.

[stevevanhooser]

Yes, some overlap. readjsonfilelocation is more tolerant (one can say 'base' and it will find the 'base.json' file wherever it lives), whereas the get_document_schema expects (and we should insist on) a full path that may include a $PATH definition. We don't want get_document_schema to look around like readjsonfilelocation; we want it to find the precise schema specified. (Basically, cases b and c from readjsonfilelocation.)

[ehennestad]

There is a tricky dependency with the ndi.common.PathConstants and did.common.PathConstants (previously initialized in the ndi.globals and did.globals) where NDI should update the $PATH definitions in the did.common.PathConstants.

This requires ndi.common.PathConstants to have been initialized whenever calling code in DID that relies on these constants that should be present in the did.common.PathConstants's definitions property.

This is not always the case. One way around is to use the startup routine, but this requires users to manually run the startup every time, and also again if variables are cleared using e.g clear all.

I think this type of dependency should be removed.

My suggestion with be the following:
When calling did.document.readjsonfilelocation from NDI, if only the document name is present, i.e "base", it should be NDI's responsibility to resolve the full path of the document, not DID.

DID could have a method for resolving these file paths (for example by extracting logic from did.document.readjsonfilelocation ) that could be called from NDI.

@stevevanhooser What do you think? Are there other places than did.document.readjsonfilelocation where this dependency is used?