Eclipse Community Forums: EMF » Calculating EClass URIs

Help

Home

Home » Modeling » EMF » Calculating EClass URIs

Show: Today's Messages :: Show Polls :: Message Navigator

Calculating EClass URIs [message #1008292]

Mon, 11 February 2013 19:25

Zoltan Ujhelyi

Messages: 392
Registered: July 2015

Senior Member

Hi,

in the EMF-IncQuery project we are trying to support developing queries for EMF models that are developed next to the queries - thus not available in the EPackage Registry. However, in our current implementation we need to translate references to a locally defined EClass reference (platform:/resource style) to an nsURI-styled one.

However, as looking the referenced EClass URIs from instance models, not all types are referenced by nsURI#//typeName style, but in case of nested packages often (but not always) they are referenced by parentURI#//packageName/typeName.

We have received several such metamodels using different nsURI schemes - in one case, new segments were added to the end of the URI; in an other the hostname was extended with subdomains.

In all cases I tried to find out when is the parent packages URI used and when not, but I didn't find any consistent theory, and even worse, I couldn't figure out where is this URI serialized.

My question would be to either describe the URI creation algorithm, or could you please point me in the direction to look for the implementation of this URI generation.

Thank you for your help,
Zoltán

PS. I know this design is not the best way to support our use cases now, but it would take a lot of effort to rewrite this entirely; and we do not have that kind of time now. So we are stuck for now with the URI conversion bit.

Report message to a moderator

Re: Calculating EClass URIs [message #1008346 is a reply to message #1008292]

Tue, 12 February 2013 05:47

Ed Merks

Messages: 33140
Registered: July 2009

Senior Member

Zoltan,

Comments below.

On 11/02/2013 8:25 PM, Zoltan Ujhelyi wrote:
> Hi,
>
> in the EMF-IncQuery project we are trying to support developing
> queries for EMF models that are developed next to the queries - thus
> not available in the EPackage Registry. However, in our current
> implementation we need to translate references to a locally defined
> EClass reference (platform:/resource style) to an nsURI-styled one.
Do you have the actual EClass instance at that point or are you working
purely with the URIs?
>
> However, as looking the referenced EClass URIs from instance models,
> not all types are referenced by nsURI#//typeName style, but in case of
> nested packages often (but not always) they are referenced by
> parentURI#//packageName/typeName.
Yes, they should be reachable from the parent.
>
> We have received several such metamodels using different nsURI schemes
> - in one case, new segments were added to the end of the URI; in an
> other the hostname was extended with subdomains.
Not sure what you mean by the last half of this sentence.
>
> In all cases I tried to find out when is the parent packages URI used
> and when not, but I didn't find any consistent theory, and even worse,
> I couldn't figure out where is this URI serialized.
Certainly when we serialize we always use the equivalent of
EcoreUtil.getURI.
>
> My question would be to either describe the URI creation algorithm, or
> could you please point me in the direction to look for the
> implementation of this URI generation.
In general, the URI for an eObject is formed from
eObject.eResource().getURI().appendFragment(eObject.eResource().getURIFragment(eObject)).
>
> Thank you for your help,
> Zoltán
>
> PS. I know this design is not the best way to support our use cases
> now, but it would take a lot of effort to rewrite this entirely; and
> we do not have that kind of time now. So we are stuck for now with the
> URI conversion bit.
Perhaps your problem is a bit similar to what we need to do when we
generate package serialization for models that will load their generated
package from a *.ecore resource:

org.eclipse.emf.codegen.ecore.genmodel.generator.GenPackageGeneratorAdapter.generatePackageSerialization(GenPackage,
Monitor)

In this case, the serialized *.ecore must refer to each other model via
its nsURI.

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: Calculating EClass URIs [message #1008440 is a reply to message #1008292]

Tue, 12 February 2013 13:54

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

Hi

I'm not quite sure what your problem is but you might find my
explanation of how platform:/... normalizes model references in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=360926#c7 useful.

Once you understand how it can work well, you can begin to understand
the pragmatic workarounds that some tools use to try to make URIs work
in standalone contexts.

Regards

Ed Willink

On 11/02/2013 19:25, Zoltan Ujhelyi wrote:
> Hi,
>
> in the EMF-IncQuery project we are trying to support developing
> queries for EMF models that are developed next to the queries - thus
> not available in the EPackage Registry. However, in our current
> implementation we need to translate references to a locally defined
> EClass reference (platform:/resource style) to an nsURI-styled one.
>
> However, as looking the referenced EClass URIs from instance models,
> not all types are referenced by nsURI#//typeName style, but in case of
> nested packages often (but not always) they are referenced by
> parentURI#//packageName/typeName.
>
> We have received several such metamodels using different nsURI schemes
> - in one case, new segments were added to the end of the URI; in an
> other the hostname was extended with subdomains.
>
> In all cases I tried to find out when is the parent packages URI used
> and when not, but I didn't find any consistent theory, and even worse,
> I couldn't figure out where is this URI serialized.
>
> My question would be to either describe the URI creation algorithm, or
> could you please point me in the direction to look for the
> implementation of this URI generation.
>
> Thank you for your help,
> Zoltán
>
> PS. I know this design is not the best way to support our use cases
> now, but it would take a lot of effort to rewrite this entirely; and
> we do not have that kind of time now. So we are stuck for now with the
> URI conversion bit.

Report message to a moderator

Re: Calculating EClass URIs [message #1008470 is a reply to message #1008346]

Tue, 12 February 2013 15:54

Zoltan Ujhelyi

Messages: 392
Registered: July 2015

Senior Member

Hi,

Comments below.

> Zoltan,
>
> Comments below.
>
> On 11/02/2013 8:25 PM, Zoltan Ujhelyi wrote:
>> Hi,
>>
>> in the EMF-IncQuery project we are trying to support developing
>> queries for EMF models that are developed next to the queries - thus
>> not available in the EPackage Registry. However, in our current
>> implementation we need to translate references to a locally defined
>> EClass reference (platform:/resource style) to an nsURI-styled one.
> Do you have the actual EClass instance at that point or are you working
purely with the URIs?

We can have the corresponding instances but with platform:/-style URI, that is different from the instance we need during query evaluation. That is we tried to solve by translating the URIs using the URI_HANDLER option of the Resource. This means, we could look at the coresponding Ecore metamodel to get the required URIs, but we need to solve the issue on the URI level.

>>
>> However, as looking the referenced EClass URIs from instance models,
>> not all types are referenced by nsURI#//typeName style, but in case of
>> nested packages often (but not always) they are referenced by
>> parentURI#//packageName/typeName.
> Yes, they should be reachable from the parent.
However, I have found cases when the parent is not used in the URI by the EMF runtime, but I don't know why. I will show an example at the end of this post.

>>
>> We have received several such metamodels using different nsURI schemes
>> - in one case, new segments were added to the end of the URI; in an
>> other the hostname was extended with subdomains.
>Not sure what you mean by the last half of this sentence.

Sorry, this really was not clear. I mistakenly believed that the fact that sometimes the URI is not used has something to do with the nsURIs of the packages.

>>
>> In all cases I tried to find out when is the parent packages URI used
>> and when not, but I didn't find any consistent theory, and even worse,
>> I couldn't figure out where is this URI serialized.
> Certainly when we serialize we always use the equivalent of
> EcoreUtil.getURI.
>>
>> My question would be to either describe the URI creation algorithm, or
>> could you please point me in the direction to look for the
>> implementation of this URI generation.
> In general, the URI for an eObject is formed from
> eObject.eResource().getURI().appendFragment(eObject.eResource().getURIFragment(eObject)).
That is true in general, however, in case of type references I did not understand how does it happen.

>>
>> Thank you for your help,
>> Zoltán
>>
>> PS. I know this design is not the best way to support our use cases
>> now, but it would take a lot of effort to rewrite this entirely; and
>> we do not have that kind of time now. So we are stuck for now with the
>> URI conversion bit.
> Perhaps your problem is a bit similar to what we need to do when we
> generate package serialization for models that will load their generated
> package from a *.ecore resource:

> org.eclipse.emf.codegen.ecore.genmodel.generator.GenPackageGeneratorAdapter.generatePackageSerialization(GenPackage,
Monitor)

> In this case, the serialized *.ecore must refer to each other model via
> its nsURI.
Thank you for the idea as it showed me that in theory non-empty parent packages are considered only (however, the getNonEmptySuperPackage method inside the GenPackageAdapter class only returns empty parent packages, if I read the code correctly).

Did I understand the code correctly, that all non-empty parent packages are considered, but none of the others? It seems to work in our examples, but I'd like to better safe than sorry.

Thanks again for the quick and helpful answer,
Zoltán

Report message to a moderator

Re: Calculating EClass URIs [message #1008476 is a reply to message #1008470]

Tue, 12 February 2013 16:18

Ed Merks

Messages: 33140
Registered: July 2009

Senior Member

Zoltan,

Comments below.

On 12/02/2013 4:54 PM, Zoltan Ujhelyi wrote:
> Hi,
>
> Comments below.
>
>> Zoltan,
>>
>> Comments below.
>>
>> On 11/02/2013 8:25 PM, Zoltan Ujhelyi wrote:
>>> Hi,
>>>
>>> in the EMF-IncQuery project we are trying to support developing
>>> queries for EMF models that are developed next to the queries - thus
>>> not available in the EPackage Registry. However, in our current
>>> implementation we need to translate references to a locally defined
>>> EClass reference (platform:/resource style) to an nsURI-styled one.
>> Do you have the actual EClass instance at that point or are you working
> purely with the URIs?
>
> We can have the corresponding instances but with platform:/-style URI,
> that is different from the instance we need during query evaluation.
> That is we tried to solve by translating the URIs using the
> URI_HANDLER option of the Resource.
I see.
> This means, we could look at the coresponding Ecore metamodel to get
> the required URIs, but we need to solve the issue on the URI level.
That sounds like a hard problem. In the URI handler you don't
generally know what the URIs purpose is, i.e., that it's mean to point
at a Ecore resource...
>
>>>
>>> However, as looking the referenced EClass URIs from instance models,
>>> not all types are referenced by nsURI#//typeName style, but in case
>>> of nested packages often (but not always) they are referenced by
>>> parentURI#//packageName/typeName.
>> Yes, they should be reachable from the parent.
> However, I have found cases when the parent is not used in the URI by
> the EMF runtime, but I don't know why. I will show an example at the
> end of this post.
Hmmm. I'll have to understand the details of what you mean.
>
>>>
>>> We have received several such metamodels using different nsURI
>>> schemes - in one case, new segments were added to the end of the
>>> URI; in an other the hostname was extended with subdomains.
>> Not sure what you mean by the last half of this sentence.
>
> Sorry, this really was not clear. I mistakenly believed that the fact
> that sometimes the URI is not used has something to do with the nsURIs
> of the packages.
I see.
>
>>>
>>> In all cases I tried to find out when is the parent packages URI
>>> used and when not, but I didn't find any consistent theory, and even
>>> worse, I couldn't figure out where is this URI serialized.
>> Certainly when we serialize we always use the equivalent of
>> EcoreUtil.getURI.
>>>
>>> My question would be to either describe the URI creation algorithm,
>>> or could you please point me in the direction to look for the
>>> implementation of this URI generation.
>> In general, the URI for an eObject is formed from
>> eObject.eResource().getURI().appendFragment(eObject.eResource().getURIFragment(eObject)).
>>
> That is true in general, however, in case of type references I did not
> understand how does it happen.
It's always a bit tricky working with development time and runtime
(generated) package instances. Ed W likes to call it metamodel
schizophrenia. :-P
>
>>>
>>> Thank you for your help,
>>> Zoltán
>>>
>>> PS. I know this design is not the best way to support our use cases
>>> now, but it would take a lot of effort to rewrite this entirely; and
>>> we do not have that kind of time now. So we are stuck for now with
>>> the URI conversion bit.
>> Perhaps your problem is a bit similar to what we need to do when we
>> generate package serialization for models that will load their generated
>> package from a *.ecore resource:
>
>> org.eclipse.emf.codegen.ecore.genmodel.generator.GenPackageGeneratorAdapter.generatePackageSerialization(GenPackage,
>>
> Monitor)
>
>> In this case, the serialized *.ecore must refer to each other model via
>> its nsURI.
> Thank you for the idea as it showed me that in theory non-empty parent
> packages are considered only (however, the getNonEmptySuperPackage
> method inside the GenPackageAdapter class only returns empty parent
> packages, if I read the code correctly).
Yet another horrible detail. Subpackages should never have been
supported. They're syntactic rat poison... :-(

You mean this code:

private EPackage getNonEmptySuperPackage(EPackage ePackage)
{
EPackage result = ePackage.getESuperPackage();
while (result != null && result.getEClassifiers().isEmpty())
{
result = result.getESuperPackage();
}
return result;
}

It keeps navigating up the eSuperPackage chain, skipping the empty ones...
>
> Did I understand the code correctly, that all non-empty parent
> packages are considered, but none of the others?
Yes, the empty ones are ignored because they aren't ever generated.
> It seems to work in our examples, but I'd like to better safe than sorry.
With nested package's there's always some tool that gets confused by
them because they're not well tested. Good that you're testing them well...
>
> Thanks again for the quick and helpful answer,
> Zoltán

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator