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

AllowedValues missing from process descriptions #41

Closed
davidcaron opened this issue May 10, 2019 · 1 comment · Fixed by #326
Closed

AllowedValues missing from process descriptions #41

davidcaron opened this issue May 10, 2019 · 1 comment · Fixed by #326
Assignees
Labels
triage/conformance Issue related to fixing/ensuring compliance to specifications. triage/investigate Exploration tasks or issues requirering more analysis

Comments

@davidcaron
Copy link
Contributor

The literal inputs' structure is not the same in the database as the one used in testbed14.

See:

  • weaver.wps_restapi.swagger_definitions.LiteralInputType: testbed14
  • weaver.wps_restapi.swagger_definitions.ProcessInputDescriptionSchema: the one in the database (it's missing the allowedValues parameter, but adding it here will not add it in the process description)

So it basically comes down to 3 options I think:

  • Ignore the inputs description in the testbed14's format, and use ours instead
  • Convert our database schema to conform to testbed14's schema
  • Write a json function to support both schemas when sending the process description

I'm not sure how much work would be involved in any of these cases...

@fmigneault
Copy link
Collaborator

fmigneault commented May 10, 2019

The ProcessInputDescriptionSchema is used for the /providers/... routes whereas the /processes/... conforms to the schemas established during TB14 with ProcessOffering->...->LiteralInputType.

Sadly, because of swagger 2.0, the oneOf doesn't display properly the ProcessInputDescriptionSchema which includes the LiteralDataDomainTypeList section nested under InputType._one_of, but only the InputDataDescriptionType fields.

Therefore, I would opt for the TB14 alternative with literalDataDomains definitions to remain consistent with the standard, and because it is the one already planed by the schema.

I can see that process https://ogc-ems.crim.ca/weaver/processes/Finch_IceDays has in the db the field allowed_values for input freq, which has all the necessary details (list of {type:allowedvalue, value: <value>, etc.}). These should be used to make the json output. I think the best place to do it is in json(), similarly how process_offering() adds extra fields on the fly.

weaver/weaver/datatype.py

Lines 700 to 713 in 65f87dd

def json(self):
# type: (...) -> JSON
return sd.Process().deserialize(self)
def process_offering(self):
# type: (...) -> JSON
process_offering = {"process": self}
if self.version:
process_offering.update({"processVersion": self.version})
if self.jobControlOptions:
process_offering.update({"jobControlOptions": self.jobControlOptions})
if self.outputTransmission:
process_offering.update({"outputTransmission": self.outputTransmission})
return sd.ProcessOffering().deserialize(process_offering)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
triage/conformance Issue related to fixing/ensuring compliance to specifications. triage/investigate Exploration tasks or issues requirering more analysis
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants