Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Docs and examples for EMF Fragment Paths?
Docs and examples for EMF Fragment Paths? [message #916578] Wed, 19 September 2012 07:32 Go to next message
Tassilo Horn is currently offline Tassilo Horn
Messages: 93
Registered: July 2009
Member
Hi all,

is there some documentation (and/or examples) of what kinds of EMF
Fragment Path expressions might show up when serializing an EMF model
using XMIResources?

If not, here're my current concrete questions:

1. In Ecore models, you have EMF Fragment Expressions like #//Foo/bar.
Do I interpret it correctly as selection based on the value of the
name-attribute? E.g., from the root element, select the child
element with name = "Foo" and from that the child element with name =
"bar".

2. In instance models serialized to XMI, you have fragments like
//@foo.bars.17. Do I interpret it correctly as selection based on
XML element name? E.g., from the root element take the single <foo>
element, then select the 17th <bars> child of it.

3. If I'm correct above, can those forms occur in a mixed form, e.g.,
something like #//Foo/baz//@bars.17? And are there other expression
kinds that can occur when saving a model to XMI?

Bye,
Tassilo
--
Dipl.-Inform. Tassilo Horn | Room: B015
University of Koblenz-Landau, Campus Koblenz | Phone: +49 (261) 287-2745
Institute for Software Technology | Mail: horn@xxxxxxxx
Universitätsstr. 1, 56070 Koblenz, Germany |
Re: Docs and examples for EMF Fragment Paths? [message #916590 is a reply to message #916578] Wed, 19 September 2012 07:51 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 26137
Registered: July 2009
Senior Member
Tassilo,

Comments below.

On 19/09/2012 9:32 AM, Tassilo Horn wrote:
> Hi all,
>
> is there some documentation (and/or examples) of what kinds of EMF
> Fragment Path expressions might show up when serializing an EMF model
> using XMIResources?
Just a bit of Javadoc. In general a resource implementation
(ResourceImpl.getURIFragment) can produce pretty much anything...
>
> If not, here're my current concrete questions:
>
> 1. In Ecore models, you have EMF Fragment Expressions like #//Foo/bar.
> Do I interpret it correctly as selection based on the value of the
> name-attribute?
Yes, you can see how this is specialized in
org.eclipse.emf.ecore.impl.EModelElementImpl.eURIFragmentSegment(EStructuralFeature,
EObject) and how its interpreted in
org.eclipse.emf.ecore.impl.EModelElementImpl.eObjectForURIFragmentSegment(String).
> E.g., from the root element, select the child
> element with name = "Foo" and from that the child element with name =
> "bar".
Exactly.
>
> 2. In instance models serialized to XMI, you have fragments like
> //@foo.bars.17. Do I interpret it correctly as selection based on
> XML element name?
Yes, but it's on the feature name, which in the presence of extended
metadata annotations could be different from the XML element name.
> E.g., from the root element take the single <foo>
> element, then select the 17th <bars> child of it.
Exactly.
>
> 3. If I'm correct above, can those forms occur in a mixed form, e.g.,
> something like #//Foo/baz//@bars.17?
In theory, yes (but the double // in front of @bars is wrong; that would
imply there is an empty segment). But note that the Foo and the baz are
specific specializations in the Ecore model.
> And are there other expression
> kinds that can occur when saving a model to XMI?
Often the fragments will be an ID not a fragment path; that's recognized
by the absence of a leading / in the fragment. With the use of
EReference.eKeys, you would also expect to see
@<feature-name>[<key1>='<value1>'{,<key-n>='<value-n'>}*]
>
> Bye,
> Tassilo
Re: Docs and examples for EMF Fragment Paths? [message #916639 is a reply to message #916590] Wed, 19 September 2012 09:02 Go to previous messageGo to next message
Tassilo Horn is currently offline Tassilo Horn
Messages: 93
Registered: July 2009
Member
Ed Merks <ed.merks@xxxxxxxx> writes:

Hi Ed,

>> 2. In instance models serialized to XMI, you have fragments like
>> //@foo.bars.17. Do I interpret it correctly as selection based on
>> XML element name?
> Yes, but it's on the feature name, which in the presence of extended
> metadata annotations could be different from the XML element name.

Ok.

>> And are there other expression kinds that can occur when saving a
>> model to XMI?
> Often the fragments will be an ID not a fragment path; that's
> recognized by the absence of a leading / in the fragment.

Ok, I've found another example:

/0/@classifiers.0/@typeParameters.0

So that means, take the 0th child element of root, then the 0th
classifiers child, and from that the 0th typeParameters element?

So I guess my previous example //@foo.bars.17 was wrong and it should
have been //@foo/@bars.17, right?

> With the use of EReference.eKeys, you would also expect to see
> @<feature-name>[<key1>='<value1>'{,<key-n>='<value-n'>}*]

Do you have an XMI file handy that contains such an expression? If so,
it'll be cool if you could send it to me (as private mail if you want).

So to sum up:

// == the root element
/17/ == the 17th child element of root
/@feature == access by feature name (which is usually the xml element
name, but not always)
/@feature.17 == positional selection
/@feature[x = '17', y = '18'] == selection by keys

Still, I'm a bit unsure what the # mark means in

#//SomeEClass/someFeature

which occurs in eOpposite-attributes in ecore models. As said, // is
the root element, /Foo is access by name-attribute equality, but what
does the # mean?

Thanks a lot,
Tassilo
--
Dipl.-Inform. Tassilo Horn | Room: B015
University of Koblenz-Landau, Campus Koblenz | Phone: +49 (261) 287-2745
Institute for Software Technology | Mail: horn@xxxxxxxx
Universitätsstr. 1, 56070 Koblenz, Germany |
Re: Docs and examples for EMF Fragment Paths? [message #916799 is a reply to message #916639] Wed, 19 September 2012 13:29 Go to previous message
Ed Merks is currently offline Ed Merks
Messages: 26137
Registered: July 2009
Senior Member
Tasslio,

I'd suggest looking closely at ResourceImpl, e.g.,
getEObject/getURIFragment and at BasicEObjectImpl's implementations of
eURIFragmentSegment and eObjectForURIFragmentSegment. This will make it
clear that the first segment is interpreted and create by the resource
implementation for locating an object within Resource.getContents() and
the remaining fragments are interpreted by the EObjects themselves for
navigating to their references.

In general an EObject is located by a URI containing a fragment. The
thing before the fragment locates the resource, and the resource uses
the fragment to locate the object within that resource. The
deserializer looks at references and if there is a #, it knows to
interpret it as a URI, if there is no #, it interprets it as only the
fragment and that the reference must be in the current resource.


On 19/09/2012 11:02 AM, Tassilo Horn wrote:
> Ed Merks <ed.merks@xxxxxxxx> writes:
>
> Hi Ed,
>
>>> 2. In instance models serialized to XMI, you have fragments like
>>> //@foo.bars.17. Do I interpret it correctly as selection based on
>>> XML element name?
>> Yes, but it's on the feature name, which in the presence of extended
>> metadata annotations could be different from the XML element name.
> Ok.
>
>>> And are there other expression kinds that can occur when saving a
>>> model to XMI?
>> Often the fragments will be an ID not a fragment path; that's
>> recognized by the absence of a leading / in the fragment.
> Ok, I've found another example:
>
> /0/@classifiers.0/@typeParameters.0
>
> So that means, take the 0th child element of root, then the 0th
> classifiers child, and from that the 0th typeParameters element?
>
> So I guess my previous example //@foo.bars.17 was wrong and it should
> have been //@foo/@bars.17, right?
>
>> With the use of EReference.eKeys, you would also expect to see
>> @<feature-name>[<key1>='<value1>'{,<key-n>='<value-n'>}*]
> Do you have an XMI file handy that contains such an expression? If so,
> it'll be cool if you could send it to me (as private mail if you want).
>
> So to sum up:
>
> // == the root element
> /17/ == the 17th child element of root
> /@feature == access by feature name (which is usually the xml element
> name, but not always)
> /@feature.17 == positional selection
> /@feature[x = '17', y = '18'] == selection by keys
>
> Still, I'm a bit unsure what the # mark means in
>
> #//SomeEClass/someFeature
>
> which occurs in eOpposite-attributes in ecore models. As said, // is
> the root element, /Foo is access by name-attribute equality, but what
> does the # mean?
>
> Thanks a lot,
> Tassilo
Previous Topic:[Teneo] Error when storing EAttribute
Next Topic:[Teneo] Recommended way to override Java to DB Type Mapping for various databases
Goto Forum:
  


Current Time: Thu Oct 23 06:00:53 GMT 2014

Powered by FUDForum. Page generated in 0.02233 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software