Xtext: refering objects from other languages; namespaces and aliases for importURI?

0
votes

I'm developing a xtext-based language which should refer to objects defined in a vendor-specific file format.

E.g. this file format defines messages, my language shall define Rules that work with these messages. Of course i want to use xtext features e.g. to autocomplete/validate message names, attributes etc.

Not sure if that is a good idea, but I came up with the following:

  • Use one xtext project to describe the file format
  • Add a dependency for this project to my DSL project, import the file format grammar to my grammar
  • import the description files via importURI

FileFormat grammar:

grammar com.example.xtext.fileformat.FileFormat;
generate fileformat "http://xtext.example.com/fileformat/FileFormat"
[...]

DSL grammar:

grammar com.example.xtext.dsl.DSL;
import "http://xtext.example.com/fileformat/FileFormat" AS ff;
Model:
    rules += Rule*;

Rule: ImportFileRule | SampleRule;
ImportFileRule: "IMPORT" importURI=STRING "AS" name=ID ";";
SampleRule: "FORWARD" msg=[ff::Message] ";"

First of all: This works fine.

Now, different imported files may define messages with colliding names, and I want to use fully qualified names for messages anyways. The prefix for the message names should be defined in my DSL, e.g. the name of the ImportFileRule.

So I would like to use something like:

IMPORT "first-incredibly-long-filename-with-version-and-stuff.ff" AS first;
IMPORT "second-incredibly-long-filename-with-version-and-stuff.ff" AS second;

FORWARD first.msg_1; // references to msg_1 in first file
FORWARD second.msg_1; // references to msg_1 in second file

Unfortunately I don't see a easy way to achieve this with xtext.

At the moment I'm using a ID for the namespace qualifier and custom ProposalProvider/Validator classes, which is ugly in detail and bypasses the EMF index, becoming slow with files of 1000 messages and 50000 attributes...

Would there be a right way to do it? Was it a good idea to use xtext to parse the definition files in the first place?

2
xtext

2 Answers

0
votes

I have two ideas what to check.

  1. Xtext has a specific global scope provider called ImportedNameSpaceAwareScopeProvider. By using an overridden version of this, you could specify other headers to consider.
  2. Check the implementation of the xtext grammar itself, as it supports such a feature with EPackage imports. I am not exactly sure, how it operates, but should work this way.
0
votes

Finally, I ended up using the SimpleNamesFragment, ImportURIScopingFragment and a custom ScopeProvider derived from AbstractDeclarativeScopeProvider.

That way, I had to implement ScopeProvider methods for quiet a few rules but was much more flexible in using my "namespace prefix". E.g. it is simple to implement syntaxes like 

FORWARD FROM first: msg_01, msg_02;