Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » EMF: Force load as a given type
EMF: Force load as a given type [message #1080666] Tue, 06 August 2013 04:31 Go to next message
Rob Mising name is currently offline Rob Mising name
Messages: 118
Registered: July 2010
Senior Member
Hi Ed,

Please can I ask your opinion on the following, I have a schema that looks as follows:

<xsd:complexType name="NewOperation">
	<xsd:sequence>
		<xsd:element name="e1" type="xsd:string"></xsd:element>
	</xsd:sequence>
</xsd:complexType>
<xsd:element name="NewOperation">
	<xsd:complexType>
		<xsd:sequence>
			<xsd:element name="in" type="xsd:string"/>
		</xsd:sequence>
	</xsd:complexType>
</xsd:element>


And when I try to load the following XML:

<file:NewOperation xsi:type="file:NewOperation"	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:file="http://www.example.org/NewFile/">
  <e1>asgdfg</e1>
</file:NewOperation>


Then it will fail. This appears to be because it is trying to load it into the object created for the element "NewOperation", instead of the one for complexType "NewOperation". So we get an error:

Caused by: java.lang.ClassCastException: org.example.NewWSDLFile.impl.NewOperationImpl cannot be cast to org.example.NewWSDLFile.NewOperationType


Due to the xsi:type="file:NewOperation" I was assuming that it would try and load it into the complexType "NewOperation" as that is the one that matches the xsi:type.

I was wondering if you had any tips of where to look for any tweaks that might enable us to support this?

Thank in advance.

Rob
Re: EMF: Force load as a given type [message #1080719 is a reply to message #1080666] Tue, 06 August 2013 06:03 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 26010
Registered: July 2009
Senior Member
Rob,

Comments below.


On 06/08/2013 10:31 AM, Rob Mising name wrote:
> Hi Ed,
>
> Please can I ask your opinion on the following, I have a schema that
> looks as follows:
>
> <xsd:complexType name="NewOperation">
> <xsd:sequence>
> <xsd:element name="e1" type="xsd:string"></xsd:element>
> </xsd:sequence>
> </xsd:complexType>
> <xsd:element name="NewOperation">
> <xsd:complexType>
> <xsd:sequence>
> <xsd:element name="in" type="xsd:string"/>
> </xsd:sequence>
> </xsd:complexType>
> </xsd:element>
>
>
> And when I try to load the following XML:
>
> <file:NewOperation xsi:type="file:NewOperation"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:file="http://www.example.org/NewFile/">
> <e1>asgdfg</e1>
> </file:NewOperation>
>
> Then it will fail. This appears to be because it is trying to load it
> into the object created for the element "NewOperation", instead of the
> one for complexType "NewOperation". So we get an error:
>
> Caused by: java.lang.ClassCastException:
> org.example.NewWSDLFile.impl.NewOperationImpl cannot be cast to
> org.example.NewWSDLFile.NewOperationType
>
> Due to the xsi:type="file:NewOperation" I was assuming that it would
> try and load it into the complexType "NewOperation" as that is the one
> that matches the xsi:type.
>
> I was wondering if you had any tips of where to look for any tweaks
> that might enable us to support this?
This instance doesn't conform to the schema. The NewOperation element
specifies an anonymous complex type so it's not possible to use an
xsi:type on such an element because the element's type has no name and
no named type can possibly be a subtype of that because an extension or
restriction would need to specify the base type by name, but it has no
name. Also the content of NewOperation must be an element named "in",
but here you have an element name "e1" so that's not going to work
either. So I'm not sure what you're trying to accomplish, but reading
an instance that doesn't conform to the schema is never going to be
possible...
>
> Thank in advance.
>
> Rob
>
Re: EMF: Force load as a given type [message #1080722 is a reply to message #1080719] Tue, 06 August 2013 06:08 Go to previous messageGo to next message
Rob Mising name is currently offline Rob Mising name
Messages: 118
Registered: July 2010
Senior Member
Hi Ed,

Thanks for taking the time to reply, in this case the schema contains both:

<xsd:complexType name="NewOperation">
	<xsd:sequence>
		<xsd:element name="e1" type="xsd:string"></xsd:element>
	</xsd:sequence>
</xsd:complexType>


and

<xsd:element name="NewOperation">
	<xsd:complexType>
		<xsd:sequence>
			<xsd:element name="in" type="xsd:string"/>
		</xsd:sequence>
	</xsd:complexType>
</xsd:element>


So the xsi:type was refering to the first complex type rather than the second anonymous complex type.

So in theory it should be a valid mapping.

Thanks

Rob
Re: EMF: Force load as a given type [message #1080753 is a reply to message #1080722] Tue, 06 August 2013 06:43 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 26010
Registered: July 2009
Senior Member
Rob,

No, even in this case the type of element "NewOperation" is still
anonymous and the complex type "NewOperation" does not extend that
anonymous type so is not substitutable via xsi:type on a "NewOperation"
element. According to your schema, a "NewOperation" element must start
with an embedded "in" element.


On 06/08/2013 12:08 PM, Rob Mising name wrote:
> Hi Ed,
>
> Thanks for taking the time to reply, in this case the schema contains
> both:
>
> <xsd:complexType name="NewOperation">
> <xsd:sequence>
> <xsd:element name="e1" type="xsd:string"></xsd:element>
> </xsd:sequence>
> </xsd:complexType>
>
> and
>
> <xsd:element name="NewOperation">
> <xsd:complexType>
> <xsd:sequence>
> <xsd:element name="in" type="xsd:string"/>
> </xsd:sequence>
> </xsd:complexType>
> </xsd:element>
>
> So the xsi:type was refering to the first complex type rather than the
> second anonymous complex type.
>
> So in theory it should be a valid mapping.
>
> Thanks
>
> Rob
Re: EMF: Force load as a given type [message #1080766 is a reply to message #1080753] Tue, 06 August 2013 06:59 Go to previous messageGo to next message
Rob Mising name is currently offline Rob Mising name
Messages: 118
Registered: July 2010
Senior Member
Hi Ed,

Sorry to disagree with you, but according to the schema spec it is valid to have this, the schema shows the case where there is BOTH

1) A complex type called NewOperation
2) An Anonymous complex type called NewOperation

So there is a traditional "name clash" at the top level, but they are of two different types (one element and one complex type), so the schema spec allows this.

This would also be the case for:

<xsd:complexType name="NewOperation">
	<xsd:sequence>
		<xsd:element name="e1" type="xsd:string"></xsd:element>
	</xsd:sequence>
</xsd:complexType>
<xsd:element name="NewOperation" type="xsd:string"/>


So one complex type and a simple element - both with the same name.

If the names do not clash then we have managed to get EMF to handle this case (By adding a hidden element into the ecore's DocumentRoot for the top level complex type - with a name matching the type).

However this does not work when there is something else with the same name as the code in:

BasicExtendedMetaData.getLocalElement(EClass eClass, String namespace, String name)


it looks for the first matching element and returns that. However in our case there could now be two with a matching name. Ideally I suppose in our situation we would also want it to somehow check the try of the element to ensure that it matches.

I hope I have done a better case of explaining what we have in our system. Any ideas or hints you have are really appreciated.

Thanks

Rob

Re: EMF: Force load as a given type [message #1080786 is a reply to message #1080766] Tue, 06 August 2013 07:25 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 26010
Registered: July 2009
Senior Member
Rob,

Comments below.

On 06/08/2013 12:59 PM, Rob Mising name wrote:
> Hi Ed,
>
> Sorry to disagree with you, but according to the schema spec it is
> valid to have this, the schema shows the case where there is BOTH
>
> 1) A complex type called NewOperation
> 2) An Anonymous complex type called NewOperation
This sentence is a contradiction. An anonymous thing has no name. You
have an element called NewOperation and yes, that isn't a name clash
with respect to a complex type called NewOperation.
>
> So there is a traditional "name clash" at the top level, but they are
> of two different types (one element and one complex type), so the
> schema spec allows this.
Yes, that's allowed.
>
> This would also be the case for:
>
> <xsd:complexType name="NewOperation">
> <xsd:sequence>
> <xsd:element name="e1" type="xsd:string"></xsd:element>
> </xsd:sequence>
> </xsd:complexType>
> <xsd:element name="NewOperation" type="xsd:string"/>
Yes that's allowed too.
>
>
> So one complex type and a simple element - both with the same name.
Yep.
>
> If the names do not clash then we have managed to get EMF to handle
> this case (By adding a hidden element into the ecore's DocumentRoot
> for the top level complex type - with a name matching the type).
Yes.
>
> However this does not work when there is something else with the same
> name as the code in:
>
> BasicExtendedMetaData.getLocalElement(EClass eClass, String namespace,
> String name)
What doesn't work?
>
> it looks for the first matching element and returns that.
There can only be one element defined for a given namespace and name.
> However in our case there could now be two with a matching name.
I've not seen you define two elements with the same name.
> Ideally I suppose in our situation we would also want it to somehow
> check the try of the element to ensure that it matches.
I don't know what you mean.
>
> I hope I have done a better case of explaining what we have in our system.
No, because everything you said above is about whether the schema is
valid, yet everything I said earlier was about whether the instance XML
conforms to the schema. It doesn't. You can't make it work. You
either have to change the schema to match your instance or you have to
change the instance conform to your schema.
> Any ideas or hints you have are really appreciated.
So again, if you have an element in your schema with an anonymous type
it will never ever be possible to use an xsi:type for that element in an
XML instance because it will never ever be possible to define a subtype
of that element's schema type because you can only define subtypes for
named types not for anonymous types.
>
> Thanks
>
> Rob
>
>
Re: EMF: Force load as a given type [message #1080862 is a reply to message #1080786] Tue, 06 August 2013 09:13 Go to previous messageGo to next message
Rob Mising name is currently offline Rob Mising name
Messages: 118
Registered: July 2010
Senior Member
Hi Ed,

Unfortunately we might have to agree to disagree with the XML semantics on this one Smile

On another note, I am aware that there is an option XMLResource.OPTION_ELEMENT_HANDLER which allows you to override the behaviour for which element is assigned to which type when you perform a save.
(I notice your EMF book states that this is designed for Save only)

Is there an equivalent thing for a load?
(i.e. given an XML object - decide which EMF object to use)

Thanks

Rob
Re: EMF: Force load as a given type [message #1080883 is a reply to message #1080862] Tue, 06 August 2013 09:41 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 26010
Registered: July 2009
Senior Member
Rob,

Comments below.

On 06/08/2013 3:13 PM, Rob Mising name wrote:
> Hi Ed,
>
> Unfortunately we might have to agree to disagree with the XML
> semantics on this one :)
I suggest that you use a validating XML parser and see if you can get it
to agree with you. I would also suggest reading
http://www.w3.org/TR/xmlschema-1/#cvc-assess-elt very carefully,
particularly 1.2.1.2.4, which makes it clear that the specified xsi:type
must be validly derived from the element's schema-specified type, which
is not the case in your example.
>
> On another note, I am aware that there is an option
> XMLResource.OPTION_ELEMENT_HANDLER which allows you to override the
> behaviour for which element is assigned to which type when you perform
> a save.
> (I notice your EMF book states that this is designed for Save only)
>
> Is there an equivalent thing for a load?
> (i.e. given an XML object - decide which EMF object to use)
I really don't know what you're trying to do. It seems nonsensical.
There is no relationship between the NewOperation element and the
NewOperation complex type so I can't imagine how you expect the model to
capture an instance of the EClass corresponding to the NewOperation
complex type (that you specify in the xsi:typ) with the instance of the
EClass corresponding to the NewOperation element's complex type (which
is created when <NewElement/> is processed). It's just not possible.
Some adjustment to your thinking is necessary...
>
> Thanks
>
> Rob
>
Re: EMF: Force load as a given type [message #1080895 is a reply to message #1080883] Tue, 06 August 2013 10:04 Go to previous messageGo to next message
Rob Mising name is currently offline Rob Mising name
Messages: 118
Registered: July 2010
Senior Member
Hi Ed,

I did previously check the schema with:
1) Eclipse
2) XMLSpy

And the schema is valid, although I do admit confusing.

From the Spec, I guess it does not need to satisfy 1.2.1.2.4 as it satisfies 1.2.1.1

If you had a schema that was just:

<xsd:complexType name="NewOperation">
	<xsd:sequence>
		<xsd:element name="e1" type="xsd:string"></xsd:element>
	</xsd:sequence>
</xsd:complexType>


Then the following XML would be fine:

<file:NewOperation xsi:type="file:NewOperation"	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:file="http://www.example.org/NewFile/">
  <e1>asgdfg</e1>
</file:NewOperation>


So adding additional information to the schema (that is still valid) and does not alter the existing definition, such as:

<xsd:element name="NewOperation">
	<xsd:complexType>
		<xsd:sequence>
			<xsd:element name="in" type="xsd:string"/>
		</xsd:sequence>
	</xsd:complexType>
</xsd:element>


Should not change that the XML is still valid.

I do want to stress that I really appreciate all the support you give on this forum, and please be assured I do spend time investigating and verifying things before I post to try and ensure I am not wasting your time.

Thanks

Rob
Re: EMF: Force load as a given type [message #1080913 is a reply to message #1080895] Tue, 06 August 2013 10:31 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 26010
Registered: July 2009
Senior Member
Rob,

Comments below.

On 06/08/2013 4:04 PM, Rob Mising name wrote:
> Hi Ed,
>
> I did previously check the schema with:
> 1) Eclipse
> 2) XMLSpy
>
> And the schema is valid, although I do admit confusing.
Yes, I keep saying the schema is valid.
>
> From the Spec, I guess it does not need to satisfy 1.2.1.2.4 as it
> satisfies 1.2.1.1
But it doesn't satisfy 1.2.2.
>
> If you had a schema that was just:
>
> <xsd:complexType name="NewOperation">
> <xsd:sequence>
> <xsd:element name="e1" type="xsd:string"></xsd:element>
> </xsd:sequence>
> </xsd:complexType>
>
> Then the following XML would be fine:
>
> <file:NewOperation xsi:type="file:NewOperation"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:file="http://www.example.org/NewFile/">
> <e1>asgdfg</e1>
> </file:NewOperation>
No because the root element must correspond to a global element declared
in the schema.
>
>
> So adding additional information to the schema (that is still valid)
> and does not alter the existing definition, such as:
>
> <xsd:element name="NewOperation">
> <xsd:complexType>
> <xsd:sequence>
> <xsd:element name="in" type="xsd:string"/>
> </xsd:sequence>
> </xsd:complexType>
> </xsd:element>
>
That declares the name for the root element so is necessary for a root
NewOperation element to be valid at all.
> Should not change that the XML is still valid.
You seem stuck on the point of schema validity which is not my point.
My point is whether the XML conforms to the valid schema.
>
> I do want to stress that I really appreciate all the support you give
> on this forum, and please be assured I do spend time investigating and
> verifying things before I post to try and ensure I am not wasting your
> time.
I can't emphasize enough that just your NewOperation element declaration
demands that if <NewOperation> appears as the root element it must
contain a nested <in> element, it's a required element in the content
type. That constraint can't be restricted away and can't be eliminated
via extension (and in any case, extension and restriction are not
possible for the anonymous complex type) so it's not possible to specify
a valid derived type via xsi:type in the XML and it's simply not
possible to avoid the necessity for an <in> element to appear...
>
> Thanks
>
> Rob
>
Re: EMF: Force load as a given type [message #1080932 is a reply to message #1080913] Tue, 06 August 2013 11:10 Go to previous messageGo to next message
Rob Mising name is currently offline Rob Mising name
Messages: 118
Registered: July 2010
Senior Member
Ah! I think I see where you are coming from now.

You mean that the: xsi:type="file:NewOperation" part in the XML is what makes it invalid - because in the first example it is refering to a type.

Then without xsi:type="file:NewOperation" in the second example - it would mean it matches with the element - then in turn has incorrect element values within the complex type.

Think I've got you now!

I guess this in turn means that there is no way of having XML validate against the complete schema, other than with the element version of "NewOperation" - it sort of "obscures" the complex type with the same name.

Thanks

Rob
Re: EMF: Force load as a given type [message #1080940 is a reply to message #1080932] Tue, 06 August 2013 11:23 Go to previous message
Ed Merks is currently offline Ed Merks
Messages: 26010
Registered: July 2009
Senior Member
Rob,

Comments below.

On 06/08/2013 5:10 PM, Rob Mising name wrote:
> Ah! I think I see where you are coming from now.
>
> You mean that the: xsi:type="file:NewOperation" part in the XML is
> what makes it invalid - because in the first example it is refering to
> a type.
Yes, so there must be a type definition for it in the schema.
>
> Then without xsi:type="file:NewOperation" in the second example - it
> would mean it matches with the element - then in turn has incorrect
> element values within the complex type.
Yes.
>
> Think I've got you now!
>
> I guess this in turn means that there is no way of having XML validate
> against the complete schema, other than with the element version of
> "NewOperation" - it sort of "obscures" the complex type with the same
> name.
Yes, the NewOperation complex type isn't really usable directly in an
xsi:type, other than for elements of type xsd:anyType.
>
> Thanks
>
> Rob
>
Previous Topic:[XCore + Git] Generated .gitignore files in src-gen
Next Topic:[Xcore] Using the same field name in subclasses
Goto Forum:
  


Current Time: Wed Aug 27 19:18:27 EDT 2014

Powered by FUDForum. Page generated in 0.04116 seconds