Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

parsing and resolving resource parameters in ocrd_network #1307

Open
bertsky opened this issue Feb 17, 2025 · 0 comments
Open

parsing and resolving resource parameters in ocrd_network #1307

bertsky opened this issue Feb 17, 2025 · 0 comments

Comments

@bertsky
Copy link
Collaborator

bertsky commented Feb 17, 2025

Another problem is with how parameter resources get resolved now. In the CLI setting, we allowed an ambiguity between JSON literals and file names, so the latter would have to be resolved to absolute paths (for the various resource locations), which in turn obviously dependend on the processor class (because of the custom module location):

if 'parameter' in kwargs:
# Disambiguate parameter file/literal, and resolve file
def resolve(name):
try:
return processor.resolve_resource(name)
except ResourceNotFoundError:
return None
kwargs['parameter'] = parse_json_string_or_file(*kwargs['parameter'],
resolve_preset_file=resolve)

But in the network setting, where parameters can be added to the processing or workflow request, no such resolution (from resource name to resource path) takes place –

  • On the server side, there is only a parameter validation step
    report = ParameterValidator(ocrd_tool).validate(dict(job_input.parameters))
  • On the client side, there is only the JSON string vs file disambiguation, but no prior resolution.
    req_params["parameters"] = set_json_key_value_overrides(parse_json_string_or_file(*parameter), *parameter_override)

Did we abandon the entire mechanism, or am I missing something?

Originally posted by @bertsky in #1303 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant