Comment 1 Ernesto Posse 2016-01-20 12:09:25 EST

Gerrit https://git.eclipse.org/r/#/c/64789/ partly solves the issue. It allows for relative paths in the same project. For references to models in other projects, 'platform:/resource/<project>/<path-to-model>' is still needed.

Comment 2 Peter Cigehn 2016-01-21 03:30:00 EST

Should the keyword 'uri' still be kept for the case of the "simplified" import statement, i.e. when you do not need to specify the complete URI (including the platform scheme and so on). Maybe the 'uri' keyword can be used when you are forced to specify a complete URI?

Like this

import "Model.umlrt"
import "../OtherDir/Model.umlrt"
import "/OtherProject/Model.umlrt"
import uri "platform:/resource/Project/Dir/Model.umlrt"
import uri "platform:/plugin/some.plugin.id/Dir/Model.umlrt"

But maybe I have to understand how the 'ns' version is supposed to work, using the "class path" (or "model path") to locate the physical model file first to know which of the two cases will be the most common and most natural. Maybe it should be the 'ns' import semantic that is the most common one, and should be able to be used without additional keyword apart from 'import'.

Comment 3 Ernesto Posse 2016-01-21 11:02:06 EST

(In reply to Peter Cigehn from comment #2)

If we drop the 'ns' form we should certainly drop the uri keyword.

Ideally we should not need a keyword at all for both cases. Maybe it will be implicit by the presence of double quotes:

import "somemodel.umlrt"

is the uri version, while

import some.element.fqn

would be the ns version.

An advantage if the second form is that we may introduce an 'as' keyword to simplify references in cases where the fqn is very long. For example, if we had:

// A.umlrt
model A
{
    package A1
    {
        package A11
        {
            protocol P1 { ... }
            //...
        }
    }
}

// B.umlrt
model B
{
    package A1
    {
        package A11
        {
            protocol P1 { ... }
            //...
        }
    }
}

Then, if we use them with the uri form, we would need to write

// C.umlrt
model C
{
    import "A.umlrt"
    import "B.umlrt"
    capsule C1
    {
        port p : A.A1.A11.P1;
        port q : B.A1.A11.P1;
        // ...
    }
}

but with the fqn form and the 'as' keyword, we could write

// C.umlrt
model C
{
    import A.A1.A11.P1 as AP1 
    import B.A1.A11.P1 as BP1
    capsule C1
    {
        port p : AP1;
        port q : BP1;
        // ...
    }
}

which would improve readability. 

This is a feature which is sadly missing in Java, but used quite effectively in languages like Haskell.

Comment 4 Peter Cigehn 2016-01-21 11:11:36 EST

How much should the import mechanism be aligned with the semantics of PackageImport and ElementImport in base UML? PackageImport imports all elements in the imported Package into the importing Namespace, basically "collapsing"/"mergin" the name space of the imported Package, whereas ElementImport only imports a single element. That element can of course could be a Package, but then the name space of that Package is kept and the contents of the imported Package is kept, and not being merged with contents of the importing name space as for the PackageImport.

And the "as" keyword as you mention seem to be well aligned with the "alias" property of the ElementImport.

Currently it feels like we only cover the semantics of the ElementImport. Is there a need to also support the semantics of PackageImport?

Comment 5 Peter Cigehn 2016-01-21 11:19:31 EST

One more thing I have been thinking about regarding the name space version of the import. Do we need to have similar naming rules as in Java, i.e. that the name of the (root) model in a file must have the same name as the physical file, or some naming scheme that makes it possible to locate the physical file from its name space? I guess that you both need the "class path" (or "model path") concept as well as the naming rule to be able to locate the physical file if you perform a name space based import? Or is there some other solution to this that I have overseen?

Comment 6 Ernesto Posse 2016-01-21 12:35:31 EST

(In reply to Peter Cigehn from comment #4)

> Currently it feels like we only cover the semantics of the ElementImport. Is
> there a need to also support the semantics of PackageImport?

Indeed, for now I've considered only the ElementImport. In theory this would be enough, but my gut feeling is that a PackageImport would be quite useful as it exists in other languages like Java. Peerhaps we could have some syntax like

import some.package.fqn.*

for PackageImport.

To me Package import is useful when you need to import a lot of elements from a package. Whether there is a need for it, perhaps you might be in a better position to tell. Are there many UML-RT models that import a lot of elements and use PackageImport for this purpose?

(In reply to Peter Cigehn from comment #5)

> One more thing I have been thinking about regarding the name space version
> of the import. Do we need to have similar naming rules as in Java, i.e. that
> the name of the (root) model in a file must have the same name as the
> physical file, or some naming scheme that makes it possible to locate the
> physical file from its name space? I guess that you both need the "class
> path" (or "model path") concept as well as the naming rule to be able to
> locate the physical file if you perform a name space based import? Or is
> there some other solution to this that I have overseen?

What is currently supported is that the physical file name and the model name are independent, so the file name does not need to match the model name and vice-versa.

If we support the namespace approach with a "model path" it may be necessary to have similar rules to Java, but I'm not entirely sure at this point. The entire "model path" could be searched for the given element, regardless of file name (looking into each file in the model path), but of course, if there is a matching name, that lookup would be more efficient, specially if the model-path includes a lot of models. Since this should work with code-completion, an efficient mechanism would be preferable.

In any case, even if the file name and model name are independent it would be good practice to use the same name.

Comment 7 Peter Cigehn 2016-01-22 03:21:47 EST

(In reply to Ernesto Posse from comment #6)
> 
> To me Package import is useful when you need to import a lot of elements
> from a package. Whether there is a need for it, perhaps you might be in a
> better position to tell. Are there many UML-RT models that import a lot of
> elements and use PackageImport for this purpose?
> 

Good question! As I see it, this highly depends on the tooling on how "models at scale" are being handled by the tool, i.e. when you decompose a model into multiple "sub-models", "fragments" and you have some aggregated "logical model". If we look at the legacy tooling for UML-RT, there has never been any need for any element/package import to be able to reference model elements in other "sub-models" in a larger "logical model", even if they where stored in a separate physical file. Take the same example with typing a port with a protocol from another model. In practice you simply did a drag-and-drop of the protocol (potentially from another model in another project) into the structure diagram of a capsule to create a port typed by that protocol. No need to do any element/package import to get hold of that protocol. Another way of doing it was to simply do as search (using a search dialog) and using an index based searching any element in the workspace could be located (even if it was not loaded into memory). In practice you had one EMF resource set for the complete workspace, which is rather different from how Papyrus handles it with one resource set per model editor.

Anyway, I do not think that we can draw any conclusion from our experience from legacy tooling, since the need for element/package import is highly dependent on the tooling support, and whether the element/package import actually is needed or not, to be able to establish references to model elements in other "models".

Exactly as you reason about searching the complete "model path", you could actually skip the import statement completely, and just assume that everything on your "model path" is available for use.

On the other hand, having explicitly documented import statements for the stuff you use from other models is rather good. But if the absolutely most common case is that you use elements from other models anyway, then the import statements will just cause an additional burden on the modeler. 

But if we compare to Java, where you actually have completion on stuff in other packages, and the actually import statement is inserted automatically, maybe this is the approach to use. We then also need to have good maintenance of the import list, comparable to the Quick Fix in JDT for cleaning up unnecessary imports and stuff like that.

I guess this is something that we need to learn as we go along... :)

Comment 8 Simon Redding 2016-02-05 16:28:54 EST

Does not gate the June release 1.0 Papyrus-RT release