Eclipse Community Forums: EMF » concrete type in xsi:type instead of element name

Home » Modeling » EMF » concrete type in xsi:type instead of element name

concrete type in xsi:type instead of element name [message #657493]

Wed, 02 March 2011 20:23

Eclipse User

I have this weird situation where i define one element of type EventProducer and a container element for it named EventDiagram where i have a reference in EventDiagram to EventProducer (0->*) called flowElements. EventProducer if of type FlowElement.

When I generate the xml from the model classes it looks like this:
<epn:EventDiagram>
<flowElements xsi:type="epn:EventProducer" id="producer1" name="producer1"/>
....
</epn:EventDiagram>

but what I am expecting it to look like is:

<epn:EventDiagram>
<epn:EventProducer" id="producer1" name="producer1"/>
....
</epn:EventDiagram>

For some reason the model is not respecting the xmlns:epn for all elements but only the root one..has anyone ran into a similar situation before? Any help is much appreciated.

Thanks.

[Updated on: Wed, 02 March 2011 20:23] by Moderator

Re: concrete type in xsi:type instead of element name [message #657497 is a reply to message #657493]

Wed, 02 March 2011 20:29

Eclipse User

Comments below.

tsurdilo wrote:
> I have this weird situation where i define one element of type
> EventProducer and a container element for it named EventDiagram where
> i have a reference in EventDiagram to EventProducer (0->*) called
> flowElements. EventProducer if of type FlowElement.
>
> When I generate the xml from the model classes it looks like this:
> <epn:EventDiagram>
> <flowElements xsi:type="epn:EventProducer" id="producer1"
> name="producer1"/>
> ...
> </epn:EventDiagram>
>
> but what I am expecting it to look like is:
>
> <epn:EventDiagram>
> <epn:EventProducer" id="producer1" name="producer1"/>
Nested element names correspond to feature names, not to type names.
> ...
> </epn:EventDiagram>
>
> For some reason the model is not respecting the xmlns:epn for all elements
What are you expecting it to respect? Feature names are generally
unqualified, at least by default.
> but only the root one..has anyone ran into a similar situation before?
All this sounds expected...
> Any help is much appreciated.
What's the problem? If you expect your results to conform to a
particular XML style, it's best you define a schema for that XML and
generate your Ecore model from that XML Schema. And then of course its
important you use the generated resource factory for producing the
resource you use to save and load instances of your model.
>
> Thanks.

Re: concrete type in xsi:type instead of element name [message #657510 is a reply to message #657497]

Thu, 03 March 2011 00:27

Eclipse User

Hi Ed, thanks for the info! I changed my approach and am creating the ecore model from a xsd. One thing I don't full understand is "Nested element names correspond to feature names, not to type names." -- how do I add a feature to an existing element with a corresponding complex type so that it is used as the name of the element? Is it using <xsd:feature .../> and is so how can I add this into for example:

<xsd:element name="myProducer" type="tMyProducer"
substitutionGroup="myElements" />
<xsd:complexType name="tMyProducer">
<xsd:complexContent>
<xsd:extension base="MyTask">
<xsd:attribute name="implementation" type="Implementation"
default="##unspecified" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>

Help is much appreciated.

Thanks.

Re: concrete type in xsi:type instead of element name [message #657642 is a reply to message #657510]

Thu, 03 March 2011 09:53

Eclipse User

shameless bump Smile

Re: concrete type in xsi:type instead of element name [message #657651 is a reply to message #657510]

Thu, 03 March 2011 10:23

Eclipse User

Comments below.

tsurdilo wrote:
> Hi Ed, thanks for the info! I changed my approach and am creating the
> ecore model from a xsd. One thing I don't full understand is "Nested
> element names correspond to feature names, not to type names." -- how
> do I add a feature to an existing element with a corresponding complex
> type so that it is used as the name of the element?
FeatureMaps...
> Is it using <xsd:feature .../> and is so how can I add this into for
> example:
>
>
> <xsd:element name="myProducer" type="tMyProducer"
> substitutionGroup="myElements" />
Where do you use myElements?
> <xsd:complexType name="tMyProducer">
> <xsd:complexContent>
> <xsd:extension base="MyTask">
> <xsd:attribute name="implementation" type="Implementation"
> default="##unspecified" />
> </xsd:extension>
> </xsd:complexContent>
> </xsd:complexType>
>
> Help is much appreciated.
Have a look at
http://ed-merks.blogspot.com/2007/12/winters-icy-grip.html to make
better use of substitution groups without wrecking your nice API.
>
> Thanks.

Re: concrete type in xsi:type instead of element name [message #657653 is a reply to message #657642]

Thu, 03 March 2011 10:27

Eclipse User

You're asking questions late in my evening. There's no need to bump it
one of my work days has gone by.

tsurdilo wrote:
> shameless bump :)

Re: concrete type in xsi:type instead of element name [message #657684 is a reply to message #657651]

Thu, 03 March 2011 11:06

Eclipse User

Your article on substitution groups helped a ton. Thank you very much!

Re: concrete type in xsi:type instead of element name [message #657685 is a reply to message #657653]

Thu, 03 March 2011 11:07

Eclipse User

Yeah sorry about the bump ..that was stupid of me

Re: concrete type in xsi:type instead of element name [message #657715 is a reply to message #657684]

Thu, 03 March 2011 11:42

Eclipse User

Who says my blogs are just pretty pictures? Those are just a bonus. :-P

tsurdilo wrote:
> Your article on substitution groups helped a ton. Thank you very much!

Previous Topic:	UnresolvedReferenceException an ID
Next Topic:	Code generation for RCP editor broken?

Goto Forum:

-=] Back to Top [=-

Current Time: Tue Jul 08 17:29:35 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter