Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Substitution groups without importing from XSD
Substitution groups without importing from XSD [message #633184] Fri, 15 October 2010 14:57 Go to next message
J.-P. Pellet is currently offline J.-P. PelletFriend
Messages: 71
Registered: July 2009
Member
Hi again,

I want to avoid the xsi:type attribute of elements in my written XML.
I've read that this can be done with substitution groups. However, I
can't seem to get this to work. I would like to specify the necessary
data form annotated Java, not from XSD. How can I do that?

I tried adding an ExtendedMetaData with a "name -> $mytagname" line and
defining an ElementHandler for saving, with no luck...

Cheers,
J.-P.
Re: Substitution groups without importing from XSD [message #633222 is a reply to message #633184] Fri, 15 October 2010 17:51 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30553
Registered: July 2009
Senior Member
J.-P.,

It's very tricky to get right. I'd suggest starting with a schema,
generating the Java, and then looking at the annotations in the
generated Java to be sure about all the little details. After that you
can continue by modifying the Java and the annotations.


J.-P. Pellet wrote:
> Hi again,
>
> I want to avoid the xsi:type attribute of elements in my written XML.
> I've read that this can be done with substitution groups. However, I
> can't seem to get this to work. I would like to specify the necessary
> data form annotated Java, not from XSD. How can I do that?
>
> I tried adding an ExtendedMetaData with a "name -> $mytagname" line
> and defining an ElementHandler for saving, with no luck...
>
> Cheers,
> J.-P.
Re: Substitution groups without importing from XSD [message #633577 is a reply to message #633222] Mon, 18 October 2010 12:44 Go to previous messageGo to next message
J.-P. Pellet is currently offline J.-P. PelletFriend
Messages: 71
Registered: July 2009
Member
Ed,

I followed your advice, and indeed, it's very tricky. It would be great
if all of this could be done with a simple annotation on the feature
that contains elements where we want to remove this xsi:type attribute.

Here's what I did to make it work, feel free to comment on what I
misunderstood.

GOAL: Given an abstract superclass SuperA with two subclasses SubA and
SubB. Another class Other holds a collections of concrete instances of
SuperA, and instead of getting the xsi:type attribute on the generated
XML, we wish to use the names of the concrete classes in the element
directly.

STEPS:
1. Be sure to have a DocumentRoot class, as some of the meta information
goes there.
2. In the superA feature of DocumentRoot, named after the abstract
superclass SuperA, add the ExtendedMetaData annotation (an annotation
with source http:///org/eclipse/emf/ecore/util/ExtendedMetaData), and
add the following entries (substituting 'superA'):
kind -> element
name -> superA
namespace -> ##targetNamespace
3. In each of the features of DocumentRoot named after the concrete
subclasses, add the following ExtendedMetaData entries:
kind -> element
name -> subX
affiliation -> superA
namespace -> ##targetNamespace
4. Finally, add the following ExtendedMetaData entries on the feature
referencing SuperA instances in the class Other:
kind -> element
name -> superA
namespace -> ##targetNamespace
5. Make sure that the following save options are set properly:
OPTION_EXTENDED_META_DATA -> Boolean.TRUE
OPTION_ELEMENT_HANDLER -> new ElementHandlerImpl(false)
6. Make sure that the following load option is set properly:
OPTION_SUPPRESS_DOCUMENT_ROOT -> Boolean.TRUE

This seems to work for me. In a kind of black-box way, but still, it
works...

Cheers,
J.-P.

On 15.10.10 19:51, Ed Merks wrote:
> J.-P.,
>
> It's very tricky to get right. I'd suggest starting with a schema,
> generating the Java, and then looking at the annotations in the
> generated Java to be sure about all the little details. After that you
> can continue by modifying the Java and the annotations.
>
>
> J.-P. Pellet wrote:
>> Hi again,
>>
>> I want to avoid the xsi:type attribute of elements in my written XML.
>> I've read that this can be done with substitution groups. However, I
>> can't seem to get this to work. I would like to specify the necessary
>> data form annotated Java, not from XSD. How can I do that?
>>
>> I tried adding an ExtendedMetaData with a "name -> $mytagname" line
>> and defining an ElementHandler for saving, with no luck...
>>
>> Cheers,
>> J.-P.
Re: Substitution groups without importing from XSD [message #633580 is a reply to message #633577] Mon, 18 October 2010 12:54 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 30553
Registered: July 2009
Senior Member
J.-P.,

Comments below.

J.-P. Pellet wrote:
> Ed,
>
> I followed your advice, and indeed, it's very tricky. It would be
> great if all of this could be done with a simple annotation on the
> feature that contains elements where we want to remove this xsi:type
> attribute.
My cup runneth over from all the things that would be so nice to have...
>
> Here's what I did to make it work, feel free to comment on what I
> misunderstood.
>
> GOAL: Given an abstract superclass SuperA with two subclasses SubA and
> SubB. Another class Other holds a collections of concrete instances of
> SuperA, and instead of getting the xsi:type attribute on the generated
> XML, we wish to use the names of the concrete classes in the element
> directly.
>
> STEPS:
> 1. Be sure to have a DocumentRoot class, as some of the meta
> information goes there.
Yes, the mapping of the feature names is based on global element
declarations, which are mapped to the document root.
> 2. In the superA feature of DocumentRoot, named after the abstract
> superclass SuperA, add the ExtendedMetaData annotation (an annotation
> with source http:///org/eclipse/emf/ecore/util/ExtendedMetaData), and
> add the following entries (substituting 'superA'):
> kind -> element
> name -> superA
> namespace -> ##targetNamespace
A global element declarations.
> 3. In each of the features of DocumentRoot named after the concrete
> subclasses, add the following ExtendedMetaData entries:
> kind -> element
> name -> subX
> affiliation -> superA
> namespace -> ##targetNamespace
Another that's in the substitution group of the previous.
> 4. Finally, add the following ExtendedMetaData entries on the feature
> referencing SuperA instances in the class Other:
> kind -> element
> name -> superA
> namespace -> ##targetNamespace
An reference to the global element declarations.
> 5. Make sure that the following save options are set properly:
> OPTION_EXTENDED_META_DATA -> Boolean.TRUE
> OPTION_ELEMENT_HANDLER -> new ElementHandlerImpl(false)
The option to save in a way that does the mapping down to the
substitution group.
> 6. Make sure that the following load option is set properly:
> OPTION_SUPPRESS_DOCUMENT_ROOT -> Boolean.TRUE
And option to load without the document root showing up
>
> This seems to work for me. In a kind of black-box way, but still, it
> works...
Very complex, but corresponding perfectly to XML Schema...
>
> Cheers,
> J.-P.
>
> On 15.10.10 19:51, Ed Merks wrote:
>> J.-P.,
>>
>> It's very tricky to get right. I'd suggest starting with a schema,
>> generating the Java, and then looking at the annotations in the
>> generated Java to be sure about all the little details. After that you
>> can continue by modifying the Java and the annotations.
>>
>>
>> J.-P. Pellet wrote:
>>> Hi again,
>>>
>>> I want to avoid the xsi:type attribute of elements in my written XML.
>>> I've read that this can be done with substitution groups. However, I
>>> can't seem to get this to work. I would like to specify the necessary
>>> data form annotated Java, not from XSD. How can I do that?
>>>
>>> I tried adding an ExtendedMetaData with a "name -> $mytagname" line
>>> and defining an ElementHandler for saving, with no luck...
>>>
>>> Cheers,
>>> J.-P.
>
Previous Topic:Abstract class with InstanceTypeName and Reflective Serialization
Next Topic:[EMF-OCL-Java] OCL Query on Ecore model from Java.
Goto Forum:
  


Current Time: Tue Oct 22 15:59:48 GMT 2019

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

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

Back to the top