Provenance for Diagnostic messages

[shaded-enmity]

We first touched this topic in #96 (comment) and I've been wondering what would be the possible solutions here. Just to properly set the context here, the problem is that LSP extensions like vscode-yaml emit diagnostic messages based on schemas provided by 3rd parties, however these messages provide no provenance as to from what 3rd party. The idea here is that we could re-purpose some fields from the original LSP spec1 - either the source field or the recently added relatedInfomation field to convey such information.

I've already started annotating schemas generated by ansible-schema-generator with a top-level $contact object:

'$contact': {
    'issues': 'https://github.com/shaded-enmity/ansible-schema-generator/issues',
    'name': 'Pavel Odvody'
}

However I feel that we might want to get broader consensus here and I'm still playing with the idea that the correct place for provenance information might be a top-level key in the LSP spec itself - to keep an account of the fact that the data which are driving the extension might be coming from a 3rd party.

[JPinkney]

I think that's a really great idea. My only concern is that i'm not entirely sure how many language servers rely on things coming from a third party. I think vscode-yaml and the yaml-language-server are more of the exception rather then the norm. I know that the json language service uses schemas as well but I believe they don't pull from the schema store.

[JPinkney]

@shaded-enmity A feature was added a little bit ago that does this: redhat-developer/yaml-language-server#326. Do you think this feature covers everything?

[gorkem]

Closing as fixed