Home » Modeling » EMF » Exctract eType from within eStructuralFeature using JET
| Exctract eType from within eStructuralFeature using JET [message #415497] |
Tue, 18 December 2007 06:07  |
Eclipse User |
|
|
|
Originally posted by: gsbhatia.gmail.com
I've created a simple Ecore model:
<?xml version="1.0" encoding="UTF-8"?>
<ecore:EPackage xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="p"
nsURI="http://p" nsPrefix="p">
<eClassifiers xsi:type="ecore:EClass" name="Foo">
<eStructuralFeatures xsi:type="ecore:EReference" name="b"
eType="#//Bar"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="Bar">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="a"
eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
</eClassifiers>
</ecore:EPackage>
If I try to load in JET via <c:load> tag dump the structure, I get the
content as:
<contents name="p" nsURI="http://p" nsPrefix="p">
<ecore:eClassifiers name="Foo">
<ecore:eStructuralFeatures name="b">
<ecore:eGenericType/>
</ecore:eStructuralFeatures>
</ecore:eClassifiers>
<ecore:eClassifiers name="Bar">
<ecore:eStructuralFeatures name="a">
<ecore:eGenericType/>
</ecore:eStructuralFeatures>
</ecore:eClassifiers>
</contents>
The type information for attributes a, and b, is hidden within
<ecore:eGenericType> tag. Is there a way to specify xpath to extract the
type information?
Thanks.
|
|
| |
| Re: Exctract eType from within eStructuralFeature using JET [message #415681 is a reply to message #415499] |
Fri, 28 December 2007 16:11  |
 Paul Elder
Messages: 849
Registered: July 2009 |
Senior Member |
|
|
Gagandeep:
Sorry for the delay in replying...
First, c:dump is a crude tool that can be helpful in debugging. But it is
very limited when it comes to interpreting things that are represented in
memory as EObjects - it completely ignores non-containment references. Also,
it adds namespace prefixes that are not required (or usable) in XPath
expressions.
The best way to think about navigating EMF-based documents with JET and
XPath is to consider the API and in particular, the eAttribute and
eReference feature names.
Lets assume you want to access information on an EAttribute. Start with the
API documentation for EAttribute:
http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse. emf.doc/references/javadoc/org/eclipse/emf/ecore/EAttribute. html
You'll see text like:
The following features are supported:
a.. ID
b.. EAttribute Type
These are the feature names (attributes and references). In this case ID is
an EAttribute and EAttribute Type is an EReference. EMF 'java-fies' these
names by removing whitespace and lowercasing the first letter, so the
runtime feature names are "iD" and "eAttributeType". JET's XPath engine uses
these names to access the object. EAttributes are treated as XPath attribute
names, EReferences as XPath element names.
Here are a number of XPath expressions that should work:
Return the name of the EAttribute type for the 'a' attribute on the 'Bar'
class
/EPackage/eClassifiers[ @name = 'Bar' ]/eAttributes[
@name='a']/eAttributeType/@name
Return the name of the referenced type for the 'b' EReference in the 'Foo'
class:
/EPackage/eClassifiers[ @name = 'Foo' ]/eReferences[ @name = 'b' ]
/eReferenceType/@name
Get the generic type information for the EReference (this comes for the
ETypedElement supertype of EReference)
/EPackage/eClassifiers[ @name = 'Foo' ]/eReferences[ @name = 'b' ]
/eGenericType/eClassifier/@name
Finally, a few more notes on how JET handles Ecore models.
1) the initial slash in an XPath expression corresponds to the 'document'.
JET maps this the the EMF Resource object from which the model is loaded.
So, the XPath expression "/" returns an
org.eclipse.emf.ecore.resource.Resource instance.
2) JET supports accessing the contents of a Resource via the 'content'
pseudo element. So the XPath expression "/contents" is the same as
Resource.getContents(). So, all of the expression above could have started
with "/contents" instead of "/EPackage"
3) When resolving an element step, if JET cannot find an EReference with the
given name, then JET will search in the objects 'contained' objects for
objects whose EClass name is the name. So /EPackage is interpreted as: all
EObjects in Resources.getContents() with eClass().getName() equal to
"EPackage". Similarly, you could have written:
/EPackage/EClass[ @name = 'Bar' ]/EAttribute[
@name='a']/eAttributeType/@name
for the first example above.
Hope this helps,
Paul
"Ed Merks" <merks@ca.ibm.com> wrote in message
news:fk8ihq$c7e$2@build.eclipse.org...
> Gagandeep,
>
> It's best to ask about JET2 on the M2T newsgroup, which I've added to the
> "to" list of the reply.
>
>
> Gagandeep Bhatia wrote:
>> I've created a simple Ecore model:
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <ecore:EPackage xmi:version="2.0"
>> xmlns:xmi="http://www.omg.org/XMI"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="p"
>> nsURI="http://p" nsPrefix="p">
>> <eClassifiers xsi:type="ecore:EClass" name="Foo">
>> <eStructuralFeatures xsi:type="ecore:EReference" name="b"
>> eType="#//Bar"/>
>> </eClassifiers>
>> <eClassifiers xsi:type="ecore:EClass" name="Bar">
>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="a"
>> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
>> </eClassifiers>
>> </ecore:EPackage>
>>
>>
>> If I try to load in JET via <c:load> tag dump the structure, I get the
>> content as:
>>
>> <contents name="p" nsURI="http://p" nsPrefix="p">
>> <ecore:eClassifiers name="Foo">
>> <ecore:eStructuralFeatures name="b">
>> <ecore:eGenericType/>
>> </ecore:eStructuralFeatures>
>> </ecore:eClassifiers>
>> <ecore:eClassifiers name="Bar">
>> <ecore:eStructuralFeatures name="a">
>> <ecore:eGenericType/>
>> </ecore:eStructuralFeatures>
>> </ecore:eClassifiers>
>> </contents>
>>
>> The type information for attributes a, and b, is hidden within
>> <ecore:eGenericType> tag. Is there a way to specify xpath to extract the
>> type information?
>>
>> Thanks.
|
|
|
| Re: Exctract eType from within eStructuralFeature using JET [message #415954 is a reply to message #415681] |
Sun, 13 January 2008 02:45 |
| Eclipse User |
|
|
|
Originally posted by: carrasco.ModelDrivenDevelopment.co.uk
This is excessively convoluted, as compared to MOFscript direct access to
features.
"Paul Elder" <pelder@ca.ibm.com> wrote in message
news:fl379d$u1e$1@build.eclipse.org...
> Gagandeep:
>
> Sorry for the delay in replying...
>
> First, c:dump is a crude tool that can be helpful in debugging. But it is
> very limited when it comes to interpreting things that are represented in
> memory as EObjects - it completely ignores non-containment references.
> Also, it adds namespace prefixes that are not required (or usable) in
> XPath expressions.
>
> The best way to think about navigating EMF-based documents with JET and
> XPath is to consider the API and in particular, the eAttribute and
> eReference feature names.
>
> Lets assume you want to access information on an EAttribute. Start with
> the API documentation for EAttribute:
>
> http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse. emf.doc/references/javadoc/org/eclipse/emf/ecore/EAttribute. html
>
> You'll see text like:
>
> The following features are supported:
> a.. ID
> b.. EAttribute Type
> These are the feature names (attributes and references). In this case ID
> is an EAttribute and EAttribute Type is an EReference. EMF 'java-fies'
> these names by removing whitespace and lowercasing the first letter, so
> the runtime feature names are "iD" and "eAttributeType". JET's XPath
> engine uses these names to access the object. EAttributes are treated as
> XPath attribute names, EReferences as XPath element names.
>
> Here are a number of XPath expressions that should work:
>
> Return the name of the EAttribute type for the 'a' attribute on the 'Bar'
> class
>
> /EPackage/eClassifiers[ @name = 'Bar' ]/eAttributes[
> @name='a']/eAttributeType/@name
>
> Return the name of the referenced type for the 'b' EReference in the 'Foo'
> class:
>
> /EPackage/eClassifiers[ @name = 'Foo' ]/eReferences[ @name = 'b' ]
> /eReferenceType/@name
>
> Get the generic type information for the EReference (this comes for the
> ETypedElement supertype of EReference)
>
> /EPackage/eClassifiers[ @name = 'Foo' ]/eReferences[ @name = 'b' ]
> /eGenericType/eClassifier/@name
>
>
> Finally, a few more notes on how JET handles Ecore models.
>
> 1) the initial slash in an XPath expression corresponds to the 'document'.
> JET maps this the the EMF Resource object from which the model is loaded.
> So, the XPath expression "/" returns an
> org.eclipse.emf.ecore.resource.Resource instance.
>
> 2) JET supports accessing the contents of a Resource via the 'content'
> pseudo element. So the XPath expression "/contents" is the same as
> Resource.getContents(). So, all of the expression above could have started
> with "/contents" instead of "/EPackage"
>
> 3) When resolving an element step, if JET cannot find an EReference with
> the given name, then JET will search in the objects 'contained' objects
> for objects whose EClass name is the name. So /EPackage is interpreted as:
> all EObjects in Resources.getContents() with eClass().getName() equal to
> "EPackage". Similarly, you could have written:
>
> /EPackage/EClass[ @name = 'Bar' ]/EAttribute[
> @name='a']/eAttributeType/@name
>
> for the first example above.
>
> Hope this helps,
>
> Paul
>
>
>
> "Ed Merks" <merks@ca.ibm.com> wrote in message
> news:fk8ihq$c7e$2@build.eclipse.org...
>> Gagandeep,
>>
>> It's best to ask about JET2 on the M2T newsgroup, which I've added to the
>> "to" list of the reply.
>>
>>
>> Gagandeep Bhatia wrote:
>>> I've created a simple Ecore model:
>>>
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <ecore:EPackage xmi:version="2.0"
>>> xmlns:xmi="http://www.omg.org/XMI"
>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="p"
>>> nsURI="http://p" nsPrefix="p">
>>> <eClassifiers xsi:type="ecore:EClass" name="Foo">
>>> <eStructuralFeatures xsi:type="ecore:EReference" name="b"
>>> eType="#//Bar"/>
>>> </eClassifiers>
>>> <eClassifiers xsi:type="ecore:EClass" name="Bar">
>>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="a"
>>> eType="ecore:EDataType
>>> http://www.eclipse.org/emf/2002/Ecore#//EString"/>
>>> </eClassifiers>
>>> </ecore:EPackage>
>>>
>>>
>>> If I try to load in JET via <c:load> tag dump the structure, I get the
>>> content as:
>>>
>>> <contents name="p" nsURI="http://p" nsPrefix="p">
>>> <ecore:eClassifiers name="Foo">
>>> <ecore:eStructuralFeatures name="b">
>>> <ecore:eGenericType/>
>>> </ecore:eStructuralFeatures>
>>> </ecore:eClassifiers>
>>> <ecore:eClassifiers name="Bar">
>>> <ecore:eStructuralFeatures name="a">
>>> <ecore:eGenericType/>
>>> </ecore:eStructuralFeatures>
>>> </ecore:eClassifiers>
>>> </contents>
>>>
>>> The type information for attributes a, and b, is hidden within
>>> <ecore:eGenericType> tag. Is there a way to specify xpath to extract the
>>> type information?
>>>
>>> Thanks.
>
>
|
|
|
| Re: Exctract eType from within eStructuralFeature using JET [message #415957 is a reply to message #415954] |
Sun, 13 January 2008 12:33 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------060409020800000709030709
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Antonio,
It seems entirely XPath-like to me. I'm having trouble imagining what's
more direct that explicitly naming a feature as part of a path
expression for navigating a chain of references. What does MOFScript
direct access to a feature look like?
Antonio Carrasco wrote:
> This is excessively convoluted, as compared to MOFscript direct access to
> features.
>
>
> "Paul Elder" <pelder@ca.ibm.com> wrote in message
> news:fl379d$u1e$1@build.eclipse.org...
>
>> Gagandeep:
>>
>> Sorry for the delay in replying...
>>
>> First, c:dump is a crude tool that can be helpful in debugging. But it is
>> very limited when it comes to interpreting things that are represented in
>> memory as EObjects - it completely ignores non-containment references.
>> Also, it adds namespace prefixes that are not required (or usable) in
>> XPath expressions.
>>
>> The best way to think about navigating EMF-based documents with JET and
>> XPath is to consider the API and in particular, the eAttribute and
>> eReference feature names.
>>
>> Lets assume you want to access information on an EAttribute. Start with
>> the API documentation for EAttribute:
>>
>> http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse. emf.doc/references/javadoc/org/eclipse/emf/ecore/EAttribute. html
>>
>> You'll see text like:
>>
>> The following features are supported:
>> a.. ID
>> b.. EAttribute Type
>> These are the feature names (attributes and references). In this case ID
>> is an EAttribute and EAttribute Type is an EReference. EMF 'java-fies'
>> these names by removing whitespace and lowercasing the first letter, so
>> the runtime feature names are "iD" and "eAttributeType". JET's XPath
>> engine uses these names to access the object. EAttributes are treated as
>> XPath attribute names, EReferences as XPath element names.
>>
>> Here are a number of XPath expressions that should work:
>>
>> Return the name of the EAttribute type for the 'a' attribute on the 'Bar'
>> class
>>
>> /EPackage/eClassifiers[ @name = 'Bar' ]/eAttributes[
>> @name='a']/eAttributeType/@name
>>
>> Return the name of the referenced type for the 'b' EReference in the 'Foo'
>> class:
>>
>> /EPackage/eClassifiers[ @name = 'Foo' ]/eReferences[ @name = 'b' ]
>> /eReferenceType/@name
>>
>> Get the generic type information for the EReference (this comes for the
>> ETypedElement supertype of EReference)
>>
>> /EPackage/eClassifiers[ @name = 'Foo' ]/eReferences[ @name = 'b' ]
>> /eGenericType/eClassifier/@name
>>
>>
>> Finally, a few more notes on how JET handles Ecore models.
>>
>> 1) the initial slash in an XPath expression corresponds to the 'document'.
>> JET maps this the the EMF Resource object from which the model is loaded.
>> So, the XPath expression "/" returns an
>> org.eclipse.emf.ecore.resource.Resource instance.
>>
>> 2) JET supports accessing the contents of a Resource via the 'content'
>> pseudo element. So the XPath expression "/contents" is the same as
>> Resource.getContents(). So, all of the expression above could have started
>> with "/contents" instead of "/EPackage"
>>
>> 3) When resolving an element step, if JET cannot find an EReference with
>> the given name, then JET will search in the objects 'contained' objects
>> for objects whose EClass name is the name. So /EPackage is interpreted as:
>> all EObjects in Resources.getContents() with eClass().getName() equal to
>> "EPackage". Similarly, you could have written:
>>
>> /EPackage/EClass[ @name = 'Bar' ]/EAttribute[
>> @name='a']/eAttributeType/@name
>>
>> for the first example above.
>>
>> Hope this helps,
>>
>> Paul
>>
>>
>>
>> "Ed Merks" <merks@ca.ibm.com> wrote in message
>> news:fk8ihq$c7e$2@build.eclipse.org...
>>
>>> Gagandeep,
>>>
>>> It's best to ask about JET2 on the M2T newsgroup, which I've added to the
>>> "to" list of the reply.
>>>
>>>
>>> Gagandeep Bhatia wrote:
>>>
>>>> I've created a simple Ecore model:
>>>>
>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>> <ecore:EPackage xmi:version="2.0"
>>>> xmlns:xmi="http://www.omg.org/XMI"
>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="p"
>>>> nsURI="http://p" nsPrefix="p">
>>>> <eClassifiers xsi:type="ecore:EClass" name="Foo">
>>>> <eStructuralFeatures xsi:type="ecore:EReference" name="b"
>>>> eType="#//Bar"/>
>>>> </eClassifiers>
>>>> <eClassifiers xsi:type="ecore:EClass" name="Bar">
>>>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="a"
>>>> eType="ecore:EDataType
>>>> http://www.eclipse.org/emf/2002/Ecore#//EString"/>
>>>> </eClassifiers>
>>>> </ecore:EPackage>
>>>>
>>>>
>>>> If I try to load in JET via <c:load> tag dump the structure, I get the
>>>> content as:
>>>>
>>>> <contents name="p" nsURI="http://p" nsPrefix="p">
>>>> <ecore:eClassifiers name="Foo">
>>>> <ecore:eStructuralFeatures name="b">
>>>> <ecore:eGenericType/>
>>>> </ecore:eStructuralFeatures>
>>>> </ecore:eClassifiers>
>>>> <ecore:eClassifiers name="Bar">
>>>> <ecore:eStructuralFeatures name="a">
>>>> <ecore:eGenericType/>
>>>> </ecore:eStructuralFeatures>
>>>> </ecore:eClassifiers>
>>>> </contents>
>>>>
>>>> The type information for attributes a, and b, is hidden within
>>>> <ecore:eGenericType> tag. Is there a way to specify xpath to extract the
>>>> type information?
>>>>
>>>> Thanks.
>>>>
>>
>
>
>
--------------060409020800000709030709
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Antonio,<br>
<br>
It seems entirely XPath-like to me. I'm having trouble imagining
what's more direct that explicitly naming a feature as part of a path
expression for navigating a chain of references. What does MOFScript
direct access to a feature look like?<br>
<br>
<br>
Antonio Carrasco wrote:
<blockquote cite="mid:fmbu0k$cqm$1@build.eclipse.org" type="cite">
<pre wrap="">This is excessively convoluted, as compared to MOFscript direct access to
features.
"Paul Elder" <a class="moz-txt-link-rfc2396E" href="mailto:pelder@ca.ibm.com"><pelder@ca.ibm.com></a> wrote in message
<a class="moz-txt-link-freetext" href="news:fl379d$u1e$1@build.eclipse.org">news:fl379d$u1e$1@build.eclipse.org</a>...
</pre>
<blockquote type="cite">
<pre wrap="">Gagandeep:
Sorry for the delay in replying...
First, c:dump is a crude tool that can be helpful in debugging. But it is
very limited when it comes to interpreting things that are represented in
memory as EObjects - it completely ignores non-containment references.
Also, it adds namespace prefixes that are not required (or usable) in
XPath expressions.
The best way to think about navigating EMF-based documents with JET and
XPath is to consider the API and in particular, the eAttribute and
eReference feature names.
Lets assume you want to access information on an EAttribute. Start with
the API documentation for EAttribute:
<a class="moz-txt-link-freetext" href=" http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse. emf.doc/references/javadoc/org/eclipse/emf/ecore/EAttribute. html"> http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse. emf.doc/references/javadoc/org/eclipse/emf/ecore/EAttribute. html</a>
You'll see text like:
The following features are supported:
a.. ID
b.. EAttribute Type
These are the feature names (attributes and references). In this case ID
is an EAttribute and EAttribute Type is an EReference. EMF 'java-fies'
these names by removing whitespace and lowercasing the first letter, so
the runtime feature names are "iD" and "eAttributeType". JET's XPath
engine uses these names to access the object. EAttributes are treated as
XPath attribute names, EReferences as XPath element names.
Here are a number of XPath expressions that should work:
Return the name of the EAttribute type for the 'a' attribute on the 'Bar'
class
/EPackage/eClassifiers[ @name = 'Bar' ]/eAttributes[
@name='a']/eAttributeType/@name
Return the name of the referenced type for the 'b' EReference in the 'Foo'
class:
/EPackage/eClassifiers[ @name = 'Foo' ]/eReferences[ @name = 'b' ]
/eReferenceType/@name
Get the generic type information for the EReference (this comes for the
ETypedElement supertype of EReference)
/EPackage/eClassifiers[ @name = 'Foo' ]/eReferences[ @name = 'b' ]
/eGenericType/eClassifier/@name
Finally, a few more notes on how JET handles Ecore models.
1) the initial slash in an XPath expression corresponds to the 'document'.
JET maps this the the EMF Resource object from which the model is loaded.
So, the XPath expression "/" returns an
org.eclipse.emf.ecore.resource.Resource instance.
2) JET supports accessing the contents of a Resource via the 'content'
pseudo element. So the XPath expression "/contents" is the same as
Resource.getContents(). So, all of the expression above could have started
with "/contents" instead of "/EPackage"
3) When resolving an element step, if JET cannot find an EReference with
the given name, then JET will search in the objects 'contained' objects
for objects whose EClass name is the name. So /EPackage is interpreted as:
all EObjects in Resources.getContents() with eClass().getName() equal to
"EPackage". Similarly, you could have written:
/EPackage/EClass[ @name = 'Bar' ]/EAttribute[
@name='a']/eAttributeType/@name
for the first example above.
Hope this helps,
Paul
"Ed Merks" <a class="moz-txt-link-rfc2396E" href="mailto:merks@ca.ibm.com"><merks@ca.ibm.com></a> wrote in message
<a class="moz-txt-link-freetext" href="news:fk8ihq$c7e$2@build.eclipse.org">news:fk8ihq$c7e$2@build.eclipse.org</a>...
</pre>
<blockquote type="cite">
<pre wrap="">Gagandeep,
It's best to ask about JET2 on the M2T newsgroup, which I've added to the
"to" list of the reply.
Gagandeep Bhatia wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I've created a simple Ecore model:
<?xml version="1.0" encoding="UTF-8"?>
<ecore:EPackage xmi:version="2.0"
xmlns:xmi=<a class="moz-txt-link-rfc2396E" href="http://www.omg.org/XMI">"http://www.omg.org/XMI"</a>
xmlns:xsi=<a class="moz-txt-link-rfc2396E" href="http://www.w3.org/2001/XMLSchema-instance">"http://www.w3.org/2001/XMLSchema-instance"</a>
xmlns:ecore=<a class="moz-txt-link-rfc2396E" href="http://www.eclipse.org/emf/2002/Ecore">"http://www.eclipse.org/emf/2002/Ecore"</a> name="p"
nsURI=<a class="moz-txt-link-rfc2396E" href="http://p">"http://p"</a> nsPrefix="p">
<eClassifiers xsi:type="ecore:EClass" name="Foo">
<eStructuralFeatures xsi:type="ecore:EReference" name="b"
eType="#//Bar"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="Bar">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="a"
eType="ecore:EDataType
<a class="moz-txt-link-freetext" href="http://www.eclipse.org/emf/2002/Ecore#//EString">http://www.eclipse.org/emf/2002/Ecore#//EString</a>"/>
</eClassifiers>
</ecore:EPackage>
If I try to load in JET via <c:load> tag dump the structure, I get the
content as:
<contents name="p" nsURI=<a class="moz-txt-link-rfc2396E" href="http://p">"http://p"</a> nsPrefix="p">
<ecore:eClassifiers name="Foo">
<ecore:eStructuralFeatures name="b">
<ecore:eGenericType/>
</ecore:eStructuralFeatures>
</ecore:eClassifiers>
<ecore:eClassifiers name="Bar">
<ecore:eStructuralFeatures name="a">
<ecore:eGenericType/>
</ecore:eStructuralFeatures>
</ecore:eClassifiers>
</contents>
The type information for attributes a, and b, is hidden within
<ecore:eGenericType> tag. Is there a way to specify xpath to extract the
type information?
Thanks.
</pre>
</blockquote>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>
--------------060409020800000709030709--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Thu Apr 25 16:17:58 GMT 2024
Powered by FUDForum. Page generated in 0.03870 seconds |
] 
Search
Help
Register
Login
Home
