Publish document

[aspino]

• [x] Append signed node headers right after publishing a new document. One of them should be the hashed user_envelope
• [ ] Sign the user envelope on behalf of the user if the payload is unsigned
• [x] Otherwise, validate signature of the received envelope
• [x] Validate metadata fields in the envelope
• [x] Validate content inside the resource data

[aspino]

@science I think I need some clarification about the resource data format validations.

What standard formats should we consider? Do all of them have standard validators we can use? What should we do in case they don't?

[science]

Right now I think you should validate as follows:

• xml => just make sure it's valid xml (for now)
• json => just make sure it's json (for now)
• json-ld + schema.org =>
  • validate that it's json-ld
  • for any recognized field, validate that the data type/structure is correct, per this example: https://gist.github.com/science/4f351ee1e9e4a476d291

For any validation failures try to provide clear feedback in return results to identify what validation element failed and why. Joe Hobson may have more input on what should be validated. Feel free to post on learningreg-dev with input on what should be validated.

[joehobson]

Our current schema validator doc for the GoOpen node is here: https://github.com/LearningRegistry/LearningRegistry/blob/goopen/LR/lr/schema/resource_lrmi_open.json

Unfortunately the LR codebase uses an older version of the jsonschema validator library (v0.8 i think) so you can't use many of the newer features - such as allowing multiple types for one element. We ran into this when trying to allow Publisher to be either a string or an object. I'm sure there are other missing features as well. Theoretically you could build out an entire validation of LRMI with distinct elements but I'm not sure how easy it would be to allow extra elements for bleeding edge stuff, or cases where systems are using their own variations of elements that aren't fully approved yet.

[science]

Thanks. I think if we validate basic stuff that's a pretty great start - and a big improvement.

The validator should ideally be extensible. Eventually it would be helpful to have it extensible outside of code - so the node can be configured to validate certain fields via config setting etc. But for the future - for now, I'd say just try to validate json-ld and if certain common schema/lrmi fields are present, make sure they are valid data types. Also url is required. I'm not sure if any other fields are required, except the envelopeLR fields.

[andersoncardoso]

I guess we can close this, right? All the publishing flow is working, and we are validating using json-schema configs. The only missing checkpoint is regarding the unsigned payloads, for now we are not accepting those. If later we decide to do this, it should be a new feature.

[science]

Agree - thanks. I'm going to add a new ticket with that feature (server-signs-on-behalf-of).