Unable to retrieve complete JSON schema

[agonzalezgaliana]

We're currently facing some problems in our prototype solution when loading the JSON Schema on our Tree Editor.

Our *.ecore model is based on an existing XSD and was generated automatically by Eclipse EMF. The resulting *.ecore file contains some dependencies to types defined in other *.ecore files from Eclipse EMF (i.e. XMLNamespace.ecore)

<eStructuralFeatures xsi:type="ecore:EAttribute" name="lang" eType="ecore:EDataType ../../org.eclipse.emf.ecore/model/XMLNamespace.ecore#//LangType">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="space" eType="ecore:EEnum ../../org.eclipse.emf.ecore/model/XMLNamespace.ecore#//SpaceType" unsettable="true">

When fetching the JSON schema from the model server (localhost:8081/api/v1/typeschema?modeluri=our.ecore), the resulting schema has actually the references to the required type:

"space": {
      "$ref": "#/definitions/spacetype"
},

However the spacetype type is NOT part of the definitions returned from the Model Server. Moreover, our tree editor implementation throws an error (via JSON Forms) claiming the same issue, that "#/definitions/spacetype" could not be found.

We're asking for some advice to know what is the problem:

• We think that our *.ecore is correct and referencing other datatypes from other *.ecore is valid. Therefore, how to generate the JSON schema valid for our *.ecore that includes all definitions from all involved *.ecore?
• Do we need to query the JSON schema for each one of the involved *.ecore and merge them afterwards?
• What could be wrong with our current approach?

Many thanks in advance.

[ndoschek]

HI @agonzalezgaliana!
I think there is an open issue on the Model Server which covers your problem eclipse-emfcloud/emfcloud-modelserver#40. Unfortunately we did not find time yet to fix this. So any help there would be much appreciated :)

In the meantime, did you try to pass no Json Type schema (undefined) (and hence let it generate from JSON Forms directly)?

[Reeze-Moodaley]

@eneufeld We would like to use the fix mentioned in #1750, however we do not have a direct dependency on Jsonforms, we make use of it through the Theia-tree-editor, Would it be possible for us to make use of the latest master changes on the Jsonforms repository in the current Theia-Tree-editor without any further changes?

If not, are you planning on releasing a Theia-tree-editor including the latest Jsonforms changes?

Thanks in advance!

[lucas-koehler]

Hello @Reeze-Moodaley, currently an update is not possible because the latest version does no contain eclipsesource/jsonforms#1750, yet. It will be included in the next beta or release version of JsonForms.

Generally, we want to go away from having a hard dependency to JsonForms and instead use a peer dependency. With this, you can then provide the JsonForms version to use yourself. We'd happily accept a contribution on this if you want to speed this along :: eclipse-emfcloud/theia-tree-editor#60

[Reeze-Moodaley]

From what I understand from your answer, the changes relating the #1750 do not break the interaction between the Theia-tree-editor and Jsonforms, therefor I assume it would be safe to proceed with cloning the Jsonforms repo and using it as a local dependency for our Theia-tree-editor.

[lucas-koehler]

@Reeze-Moodaley Yes, that could work.

[agonzalezgaliana]

@ndoschek by returning undefined the error does not appear. It's a nice "temporary workaround" because it allows us to continue researching and testing the tree editor. However we're still trying to implement a better workaround.

[vhemery]

I have solved cases with multiple dynamic EMF metamodels (dynamic = java sources not generated), so there definitely is a way to solve your problem.

First of all, relative URIs can be tricky. So I suggest using absolute URIs with URI mappings instead. For your example, use "http://www.w3.org/XML/1998/namespace#//LangType" instead of "../../org.eclipse.emf.ecore/model/XMLNamespace.ecore#//LangType". You can safely make a replace all in a text editor for ""../../org.eclipse.emf.ecore/model/XMLNamespace.ecore#/" then open your metamodel again to check that all references are correctly resolved.

Then, about the schema resolution itself :
In JsonFormsDetailConfig, there is a 'refParserOptions' entry. There you can pass an object that will tell how to resolve the schemas (in collaboration with Ajv).
My code looks like :

        // configure Ajv with required schemas
        this.ajv = createAjv();
        const schemas = await this.getSchemaDefinitions();
        schemas.forEach((schema, key) => this.ajv.addSchema(schema, key));
        // allow schema ref resolution
        this.refParserOptions = {
            resolve: {
                external: true,
                http: {
                    order: 1,
                    canRead: function (file) {
                        return schemas.has(file.url);
                    },
                    read: function (file) {
                        return JSON.stringify(schemas.get(file.url));
                    }
                }
            }
        };

where getSchemaDefinitions loads first all the schemas I will need (well my personal method is a bit more complicated, because I do not always need the same schemas). To solve these schemas, you can call the getTypeSchema endpoint on the EMF.cloud model server.
Then, it's up to your backend model repository implementation, which by default, delegates to your backend ModelResourceManger's implementation where you can override the methods org.eclipse.emfcloud.modelserver.emf.common.DefaultModelResourceManager.loadResource(String) if everything does not already go smoothly.

[vhemery]

This solution worked for the jsonforms version I have been using (2.5.0), but as @eneufeld mentions (while I was redacting it), this will most probably be impacted by eclipsesource/jsonforms#1750
So I'll have to check that it still works with latest versions.

[agonzalezgaliana]

Thanks @vhemery for the mentioned solution. I think we can implement something similar on our side. However, correct me if I'm wrong, in your scenario seems that the $refs are file or http URIs. Without having tested a $ref resolve library as json-refs yet, I have the feeling that the $ref returned by the Model Server is simply wrong because it is a local reference when in fact should be an external reference.

On the other side, I do not completely understand the second part of of your proposal where you mention some changes to be done in the ModelResourceManager. What's the purpose of that?

[vhemery]

In my scenario, $refare http URIs, which are mapped in the EMF model server to platform:/plugin URIs.
So my frontend sees only http URIs, and asks the model server to resolve them.

The last part on the ModelResourceManager, and I insist on the

if everything does not already go smoothly.

is so that the model server can actually find the corresponding Ecore resource to return the correct schema to the API.
My model server has quite a lot of customizations, so I'm not sure how much is already resolved with the default implementation. But in the end, I delegate all schema resolutions to EMF resource loading and URI mapping.
I expect the resource loading to work seamlessly, but I'm not 100% sure that the default ModelResourceManager will not stick to its workspace greedy-loaded known implementations by default. And it may also have changed with the v2 API...

[agonzalezgaliana]

Hi @vhemery, thanks to your proposal we were able to solve the issue.

We've customized the DefaultJsonSchemaConverter from the model server to return valid external $refs (i.e. with an http URI).
Then on the client side:

• Request first all required schemas from the ModelServer and build a map <URI, Schema>.
• Use @apidevtools/json-schema-ref-parser to create a custom HTTP $ref resolver which returns the corresponding schema based on the required file.url