Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Custon type in <xs:list>(How to force element type in lists in an XSD-generated model ?)
Custon type in <xs:list> [message #1410236] Wed, 20 August 2014 07:09 Go to next message
Gordan Vosicki is currently offline Gordan VosickiFriend
Messages: 13
Registered: March 2013
Junior Member
The default generated type can easily be changed for an attribute or an element with the ecore:type attribute in the schema file:

<xs:attribute name="crc" type="xs:integer" ecore:type="ecore:ELongObject"/>

But how can one change the generated type of liste elements produced by an <xs:list> decalration ?
The following patterns don't seem to work:

<xs:simpleType name="FaceType" ecore:type="ecore:EInt">
	<xs:list itemType="xs:integer" ecore:type="ecore:EInt"/>
</xs:simpleType>


The same question applies to types generated by restriction:

<xs:simpleType name="zoneNumberType" ecore:type="ecore:EInt">
	<xs:restriction base="xs:positiveInteger" ecore:type="ecore:EInt">
		<xs:minInclusive value="1"/>
		<xs:maxInclusive value="99"/>
	</xs:restriction>
</xs:simpleType>
Re: Custon type in &lt;xs:list&gt; [message #1410260 is a reply to message #1410236] Wed, 20 August 2014 08:34 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Gordan,

Comments below.

On 20/08/2014 9:09 AM, Gordan Vosicki wrote:
> The default generated type can easily be changed for an attribute or
> an element with the ecore:type attribute in the schema file:
>
> <xs:attribute name="crc" type="xs:integer"
> ecore:type="ecore:ELongObject"/>
>
> But how can one change the generated type of liste elements produced
> by an <xs:list> decalration ?
> The following patterns don't seem to work:
>
> <xs:simpleType name="FaceType" ecore:type="ecore:EInt">
> <xs:list itemType="xs:integer" ecore:type="ecore:EInt"/>
> </xs:simpleType>
You opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=441901 for this.

You could define, in a different Ecore model, an EDataType for
java.util.List<java.lang.Integer> and use that type on the simpleType.
Being able to specify the type of the item would be handy, but that's a
feature not-yet-supported
>
>
> The same question applies to types generated by restriction:
>
> <xs:simpleType name="zoneNumberType" ecore:type="ecore:EInt">
> <xs:restriction base="xs:positiveInteger" ecore:type="ecore:EInt">
What would be accomplished by specifying this in the restriction that
isn't already accomplished specifying it on the simple type?
> <xs:minInclusive value="1"/>
> <xs:maxInclusive value="99"/>
> </xs:restriction>
> </xs:simpleType>
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Custon type in &lt;xs:list&gt; [message #1413252 is a reply to message #1410260] Thu, 28 August 2014 06:42 Go to previous messageGo to next message
Gordan Vosicki is currently offline Gordan VosickiFriend
Messages: 13
Registered: March 2013
Junior Member
Thanks Ed for your proposal, this might be a solution.
Just a silly question:

As the XSD file has to be modified anyhow until there is a way to define additonal things (like ecore:type) outside the original file (like in JAXB), I could also simply replacee the xs:integer and xs:positiveInteger types by xs:int or xs:long.

Would the XML read/write functions still work if I made this simpler change ?

Another point:
These lists have potentially hundreds of thousands of elements.
I would prefer to use collection classes containing arrays of simple types instead of objects (int instead of Integer). We already have such classes, which actually implement java.util.List, and it would be easy to add support for EList.

Is there a more elegant way to do it than to modify by hand the generated factory methods ?
    public List<BigInteger> createFaceTypeFromString(EDataType eDataType, String initialValue);
    public String convertFaceTypeToString(EDataType eDataType, Object instanceValue);

Is there anything else which has to be done for this, I personally hate modifying generated code ?
Re: Custon type in &amp;lt;xs:list&amp;gt; [message #1413264 is a reply to message #1413252] Thu, 28 August 2014 07:05 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Gordan,

Comments below.

On 28/08/2014 8:42 AM, Gordan Vosicki wrote:
> Thanks Ed for your proposal, this might be a solution.
> Just a silly question:
>
> As the XSD file has to be modified anyhow until there is a way to
> define additonal things (like ecore:type) outside the original file
> (like in JAXB),
This relies only on an xmlns declaration and that declaration must be in
the XSD itself to be used there, so no. Given the nature of where these
annotations can appear (i.e., in all kinds of nested content) it's
significantly pretty tricky to define an external mapping and the
implementation of an authoring tool for doing so is also a significant
undertaking.
> I could also simply replacee the xs:integer and xs:positiveInteger
> types by xs:int or xs:long.
Yes.
>
> Would the XML read/write functions still work if I made this simpler
> change ?
Yes, in the end this only affects the conversion of strings in the XML
to Java instances so assuming the strings conform to the value range
implied by those Java types, it should all parse and serialize in the
expected/correct way.
>
> Another point:
> These lists have potentially hundreds of thousands of elements.
> I would prefer to use collection classes containing arrays of simple
> types instead of objects (int instead of Integer). We already have
> such classes, which actually implement java.util.List, and it would be
> easy to add support for EList.
I see. It's always possible to use your own custom data types...
>
> Is there a more elegant way to do it than to modify by hand the
> generated factory methods ?
> public List<BigInteger> createFaceTypeFromString(EDataType
> eDataType, String initialValue);
> public String convertFaceTypeToString(EDataType eDataType, Object
> instanceValue);
Somewhere you need to have had written code. You could do that in
another model and specify that model's type as the ecore:type (or define
that other model as an XML Schema and change the actual schema type= to
use that model's simple type).
>
> Is there anything else which has to be done for this, I personally
> hate modifying generated code ?
Yes, some folks have a strong aversion to that. At some point I'll look
at generalizing the generation-gap pattern and supporting it more
broadly, but that's also a significant undertaking (complicated by the
trickiness of finding custom overrides automatically in either source or
on the classpath)...


Ed Merks
Professional Support: https://www.macromodeling.com/
Previous Topic:[CDO] Delete values from version history
Next Topic:[CDO] Old class cast exception resurfaces
Goto Forum:
  


Current Time: Fri Mar 29 09:35:23 GMT 2024

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

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

Back to the top