Provide quickfix for missing classes and properties

[mchlrch]

For example with the following mapping (based on mapping-examples/airport-mapping)

map AirportMapping from airport {
    subject template "http://airport.example.com/{0}" with id

    types transit.Stop

    properties
    ex.bla
}

We get a linking error in the mapping definition: couldn't resolve reference to RdfProperty 'ex.bla' Because neither vocabulary ex nor property bla is defined.

Ideally, we could provide a quickfix

• ... that would add a new (property|class) to an already existing vocabulary (eg. for transit.Foo)
• ... that would add a new vocabulary and (property|class) otherwise (eg. for ex.bla)

[nicky508]

I found we could solve this in two ways. Give the user a warning and create in the background the quickfixes. Or show the user a sort auto completion tooltip to create the vocab with/or only the property of class automatically.

[ktk]

in openrefine I can say "add" which will then add it even though it does not know the context. I like the idea of adding it to a sample namespace, I think that is very realistic in the real world. But it should at the same time be clear that I cannot simply extend existing namespaces that way so we should have it somewhat explicit.

[nicky508]

in openrefine I can say "add"

I think it is what Michael meant. I got a quickfix on the missing property now: "Add property to vocabulary" (not fully implemented, yet). I think is also good for the user to know what is happing.

[nicky508]

@mchlrch Did you do something somewhere in the code to use multiple files when generating rml? I am working on the quickfix, but I am only able to reach code in the mapping file itself, not in the vocabularies file for example. Only the file in which I am working.

[mchlrch]

I didn't have to do anything for that in the generator, because in the generator I'm only following references (that might point into other files) and loading the corresponding model is done by Xtext behind the scenes.

Xtext does lazy linking. In case you have a proxy object, then one of the resolve() methods from org.eclipse.xtext.EcoreUtil2 might get you the full EObject.

If there is not even a proxy object, then one way to consider/access content from other files is to do that viaorg.eclipse.xtext.resource.IResourceDescription.getExportedObjects()

This approach is used for example in org.eclipse.xtext.validation.NamesAreUniqueValidator and org.eclipse.xtext.validation.NamesAreUniqueValidationHelper.

The IResourceDescription is what the index is working with. There is some documentation about it under Scoping

[mchlrch]

Maybe a vocabulary in the DSL could explicitly declare that it is extendable. And only in that case a quickfix should be proposed for adding a new (property|class) to it.

If I have two extendable vocabularies ex and foo, then ideally:

• ex:fiz would lead to one quickfix add ex:fiz
• bar:faz would lead to two quickfixes add ex:faz and add foo:faz

[nnamtug]

note: the trick is to provide a quick fix (or more than 1) to the default linkage error from xtext

So it is something like this in the QuickfixProvider:

    @Fix(Diagnostic.LINKING_DIAGNOSTIC)
    public void createMissingStuff(Issue issue, IssueResolutionAcceptor acceptor) {
        acceptor.accept(issue, "create new Property", "create new Property", null, new MyPropertyCreateionModificator(...));
        // ... more resolutions here, if applicable

[mchlrch]

I tested the variations documented in runtime-EclipseXtext/editor-test/foo-mapping.xrm All of them worked. Closing this