Eclipse Community Forums: EMF » Forcing xsi:type on the top level element

Help

Home

Home » Modeling » EMF » Forcing xsi:type on the top level element

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

Forcing xsi:type on the top level element [message #718882]

Thu, 25 August 2011 14:45

Rob Mising name

Messages: 118
Registered: July 2010

Senior Member

Hi,

I was wondering, is there a way that I can get the xsi:type forced to be displayed on the top level element when save is invoked. I already have:

XMLResource.OPTION_SAVE_TYPE_INFORMATION, new MyXMLTypeInfo()

Set and it gets called (and true is returned in all cases other than anonymous types).

However I have noticed that it does not get called for the top level element.

So for clarity, if I the following schema:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="http://www.examples.com/TypeConvert" targetNamespace="http://www.examples.com/TypeConvert">
	<xs:complexType name="TypeConvertComplex">
		<xs:sequence>
			<xs:element name="stringValue" type="xs:string" minOccurs="0" maxOccurs="1"/>
		</xs:sequence>
	</xs:complexType>
	<xs:element name="TypeConvertElement" type="TypeConvertComplex"/>
</xs:schema>

then I'd like the XML to look like:

<ts1:TypeConvertElement xmlns:ts1="http://www.examples.com/TypeConvert" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ts1:TypeConvertComplex">
	<stringValue xmlns="">String</stringValue>
</ts1:TypeConvertElement>

If anyone has any suggestions then that would be great.

Thanks

Rob

EMF 2.4.2

Report message to a moderator

Re: Forcing xsi:type on the top level element [message #718949 is a reply to message #718882]

Thu, 25 August 2011 16:12

Ed Merks

Messages: 33142
Registered: July 2009

Senior Member

Rob,

Comments below.

On 25/08/2011 7:45 AM, Rob wrote:
> Hi,
>
> I was wondering, is there a way that I can get the xsi:type forced to
> be displayed on the top level element when save is invoked. I already
> have:
>
> XMLResource.OPTION_SAVE_TYPE_INFORMATION, new MyXMLTypeInfo()
>
> Set and it gets called (and true is returned in all cases other than
> anonymous types).
Indeed, anonymous types have no name and hence can't be used for an
xsi:type...
>
> However I have noticed that it does not get called for the top level
> element.
Do you have a DocumentRoot instance at the root of the resource?
>
> So for clarity, if I the following schema:
>
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
> xmlns="http://www.examples.com/TypeConvert"
> targetNamespace="http://www.examples.com/TypeConvert">
> <xs:complexType name="TypeConvertComplex">
> <xs:sequence>
> <xs:element name="stringValue" type="xs:string" minOccurs="0"
> maxOccurs="1"/>
> </xs:sequence>
> </xs:complexType>
> <xs:element name="TypeConvertElement" type="TypeConvertComplex"/>
> </xs:schema>
>
> then I'd like the XML to look like:
>
> <ts1:TypeConvertElement
> xmlns:ts1="http://www.examples.com/TypeConvert"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:type="ts1:TypeConvertComplex">
> <stringValue xmlns="">String</stringValue>
> </ts1:TypeConvertElement>
>
> If anyone has any suggestions then that would be great.
So you're trying to force a redundant xsi:type?
>
> Thanks
>
> Rob
>
> EMF 2.4.2
>

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

Report message to a moderator

Re: Forcing xsi:type on the top level element [message #718959 is a reply to message #718882]

Thu, 25 August 2011 16:37

Rob Mising name

Messages: 118
Registered: July 2010

Senior Member

Hi Ed, Thanks for taking the time to respond.

Quote:

Do you have a DocumentRoot instance at the root of the resource?

There will be a document root, at this part of the code we are just converting a single EObject, we have used XMLResource.OPTION_ELEMENT_HANDLER in order implement some code that "picks" an element based off of the EObject type.

Quote:

So you're trying to force a redundant xsi:type?

I suppose from this point of view yes - but it will be important for what we do with the XML in the application.

Do you have any thoughts on the best way of adding this - I was really hoping to not have to post process the XML generated from save, but use a more "inclusive" solution.

Thanks

Rob

Report message to a moderator

Re: Forcing xsi:type on the top level element [message #719095 is a reply to message #718959]

Fri, 26 August 2011 03:45

Ed Merks

Messages: 33142
Registered: July 2009

Senior Member

Rob,

I really mean a DocumentRoot, not just any old object that's the root of
the document/resource. It's an EClass that's generated when there are
global elements. If you look at the generated XyzExample.java you get
when you invoke Generate Test Code, you'll see how it's used.

On 25/08/2011 9:37 AM, Rob wrote:
> Hi Ed, Thanks for taking the time to respond.
>
> Quote:
>> Do you have a DocumentRoot instance at the root of the resource?
>
>
> There will be a document root, at this part of the code we are just
> converting a single EObject, we have used
> XMLResource.OPTION_ELEMENT_HANDLER in order implement some code that
> "picks" an element based off of the EObject type.
>
> Quote:
>> So you're trying to force a redundant xsi:type?
>
>
> I suppose from this point of view yes - but it will be important for
> what we do with the XML in the application.
>
> Do you have any thoughts on the best way of adding this - I was really
> hoping to not have to post process the XML generated from save, but
> use a more "inclusive" solution.
>
> Thanks
>
> Rob
>

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

Report message to a moderator

Re: Forcing xsi:type on the top level element [message #724968 is a reply to message #719095]

Tue, 13 September 2011 15:50

Rob Mising name

Messages: 118
Registered: July 2010

Senior Member

Hi Ed,

Very sorry for going quiet - customer issues to look at have kept me busy for a little while!!

I appreciate you taking the time to reply. I have had a chance to look a little deeper into this. I spotted:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=296144

Which you put a fix into 2.6 for, unfortunately I am on 2.4.2 I have had a little go at patching this area on my test machine and have one question. With the additional if's that look as follows (there are two):

if (rootFeature != null && rootFeature.getEType() != eClassifier)
{
    shouldSaveType = true;
}

it will force the xsi:type to be added if they are required for clarity, however, should it also ideally check to see if the OPTION_SAVE_TYPE_INFORMATION option has been set to enable "forcing" of xsi:type, something like:

if (rootFeature != null && ((xmlTypeInfo.shouldSaveType(eClass, rootFeature.getEType(), rootFeature)) ||(rootFeature.getEType() != eClassifier)) ) 
{
    shouldSaveType = true;
}

The arguments are most probably completely wrong in my example and maybe also the logic, but I'm wondering if in this instance it should check to see if the xsi:type is being forced in some way?

Thanks

Rob

[Updated on: Tue, 13 September 2011 15:59]

Report message to a moderator

Re: Forcing xsi:type on the top level element [message #724994 is a reply to message #724968]

Tue, 13 September 2011 16:14

Ed Merks

Messages: 33142
Registered: July 2009

Senior Member

Rob,

I suppose it should but it's hard to imagine ever wanting to force an
xsi:type on the root. Even this case looks like a poor schema design
that's better addressed by changing the schema than by using an xsi:type.

On 13/09/2011 8:50 AM, Rob wrote:
> Hi Ed,
>
> Very sorry for going quiet - customer issues to look at have kept me
> busy for a little while!!
>
> I appreciate you taking the time to reply. I have had a change to
> look a little deeper into this. I spotted:
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=296144
>
> Which you put a fix into 2.6 for, unfortunately I am on 2.4.2 I have
> had a little go at patching this area on my test machine and have one
> question. With the additional if's that look as follows (there are two):
>
> if (rootFeature != null && rootFeature.getEType() != eClassifier)
> {
> shouldSaveType = true;
> }
>
> it will force the xsi:type to be added if they are required for
> clarity, however, should it also ideally check to see if the
> OPTION_SAVE_TYPE_INFORMATION option has been set to enable "forcing"
> of xsi:type, something like:
>
> if (rootFeature != null && ((xmlTypeInfo.shouldSaveType(eClass,
> rootFeature.getEType(), rootFeature)) ||(rootFeature.getEType() !=
> eClassifier)) ) {
> shouldSaveType = true;
> }
>
> The arguments are most probably completely wrong in my example and
> maybe also the logic, but I'm wondering if in this instance it should
> check to see if the xsi:type is being forced in some way?
>
> Thanks
>
> Rob
>

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

Report message to a moderator

Re: Forcing xsi:type on the top level element [message #725197 is a reply to message #724994]

Wed, 14 September 2011 08:10

Rob Mising name

Messages: 118
Registered: July 2010

Senior Member

Ed Merks wrote on Tue, 13 September 2011 17:14

I suppose it should but it's hard to imagine ever wanting to force an
xsi:type on the root. Even this case looks like a poor schema design
that's better addressed by changing the schema than by using an xsi:type.

Hi Ed,

Unfortunately the system we are using requires that we explicitly specify the xsi:type at every level so that it can be parsed to work out the type info (long story!).

We originally thought that OPTION_SAVE_TYPE_INFORMATION would do this for us - and it does, with the small exception of this top level case.

Is this something that you would be willing to concider? If not then I am able to patch it, just thought that this may be nice from a consistancy point of view?

Thanks

Rob

Report message to a moderator

Re: Forcing xsi:type on the top level element [message #725308 is a reply to message #725197]

Wed, 14 September 2011 13:25

Ed Merks

Messages: 33142
Registered: July 2009

Senior Member

Rob,

Sure, open a bugzilla for it. Of course it will only be done in 2.8...

On 14/09/2011 1:10 AM, Rob wrote:
> Ed Merks wrote on Tue, 13 September 2011 17:14
>> I suppose it should but it's hard to imagine ever wanting to force an
>> xsi:type on the root. Even this case looks like a poor schema design
>> that's better addressed by changing the schema than by using an
>> xsi:type.
>
>
> Hi Ed,
>
> Unfortunately the system we are using requires that we explicitly
> specify the xsi:type at every level so that it can be parsed to work
> out the type info (long story!).
>
> We originally thought that OPTION_SAVE_TYPE_INFORMATION would do this
> for us - and it does, with the small exception of this top level case.
>
> Is this something that you would be willing to concider? If not then
> I am able to patch it, just thought that this may be nice from a
> consistancy point of view?
>
> Thanks
>
> Rob
>

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

Report message to a moderator