rethink abstract data class

[pchainho]

A rethink data class that implements a validate function against a json-schema identified by a Catalogue URL that can be retrieved from the Catalogue Runtime. This function is called in debug mode. All other reTHINK data classes that should comply with a standard json-schema will extend from this abstract data class.

[emmelmann-fokus]

I don't understand why people need to be provided with the json-schemas in a running deployment with tested code? Because this would be the only reason for providing those json-schemas by the Catalogue.

Isn't this validation only needed during the debugging / development phase in which the developer has anyway checked out or at least have access to the GitHub repository?

Anyway, if the catalogue is going to host json-schemas, here is the only way this can be done right now:

The json-schema will be contained in a standard catalogue object, i.e. the object will basically contain the same elements as a hyperty object except that in the "sourcePackage" element, the json-schema will be contained.

The path to acces the object will be according to the agreed resource path definition.

In practice, as json-schema might reference each other, this would mean that one json-schema will have to be downloaded from the catalogue, then be parsed to identify potentially references other schemas, and then the catalogue needs to be re-contacted to retrieve all of those (newly) identified schemas. Note that this will be a recursive process that will involve several contact requests to the catalogue.

Given that the schemas are only needed for testing & development, I think it is sufficient to have them as part of the GitHub Repository which then can be checked out into a local copy.

[pchainho]

The json-schema can also be used in the runtime eg to check compliancy between two different hyperties (not yet specified) and to manage data synchronisation between Hyperties.

[acheambe]

@pchainho Is this a functionality for the runtime still to be specified in the future? The issue i see with this approach as @emmelmann-fokus pointed out is the cross referencing within the json-schema presently. For one validation check, the catalogue will have to be contacted multiple times to retrieve all internal referenced documents. At these referenced documents in turn reference other documents and so forth until it gets to the node of the reference tree.

Since this functionality is to be used at development phase and not production phase, it simplifies things if let in the dev-service-framework repository. what do you think?

[pchainho]

the usage of data schemas for data synchronisation is already specified and it is planed for phase 1 and shouldn't imply to go through all these dependencies tree

However it should be noted, the data synchronisation requirement is not directly related with this abstract class to be used in debug modeto validate the data schema. It only implies the need to have data schemas in the catalogue.

[pchainho]

The Json-schema for the validation of data objects used in the data synchronisation between hyperties are ready and available here

@acheambe pls provide us some feedback

thx

[pchainho]

What is the status of this one?

[Endebert]

I went ahead and extended the (optional) vaidation of RethinkObjects

Now the question is when to use this feature. It works well in the karma tests, for example I added validation as part of the tests for the MessageFactory

The object validation I added to the SyncherManager in dev-runtime-core works similarly, but doesn't need the RethinkObject class.

In both cases, we have to enforce that the schemas that are being validated against do not contain any references to other schemas, since they might not be resolveable. For the validation with RethinkObjects in karma tests, I suggest the provision of another set of json schemas, that are also contained in dev-service-framework, but have their references already resolved. I believe that could be done easily with a gulp task.

[Endebert]

Since this issue is about the RethinkObject class, which is implemented and contains validation functionalities, this issue can be closed.

The gulp task I mentioned in my previous comment has been added by me some time ago