Eclipse Community Forums: EMF » [XSD2Ecore] is removing removing underscore from EEnumLiteral name and not setting literal

Home » Modeling » EMF » [XSD2Ecore] is removing removing underscore from EEnumLiteral name and not setting literal

[XSD2Ecore] is removing removing underscore from EEnumLiteral name and not setting literal [message #984678]

Wed, 14 November 2012 17:21

Eclipse User

I'm running into a name mapping problem where XSD2Ecore is mapping an Restriction with Enumeration Facets to an EENum. Each enumeration value has an underscore, but the corresponding EEnumLiteral's name has the underscore removed and the it's literal is not properly set to original value either. I'll add I don't think removing the underscore should be required to make it a valid Java name anyway.

Is this a bug or am I missing an option somewhere?

Thanks,
dave

Here is the XSD snippet:

    <xsd:simpleType name="DATA-TYPE">
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="A_INT32"/>
            <xsd:enumeration value="A_UINT32"/>
            <xsd:enumeration value="A_FLOAT32"/>
            <xsd:enumeration value="A_FLOAT64"/>
            <xsd:enumeration value="A_ASCIISTRING"/>
            <xsd:enumeration value="A_UTF8STRING"/>
            <xsd:enumeration value="A_UNICODE2STRING"/>
            <xsd:enumeration value="A_BYTEFIELD"/>
        </xsd:restriction>
    </xsd:simpleType>

And here is generated Ecore (in OCLinEcore):

	enum DATATYPE { serializable }
	{
		annotation _'http:///org/eclipse/emf/ecore/util/ExtendedMetaData'
		(
			name = 'DATA-TYPE'
		);
		literal AINT32;
		literal AUINT32 = 1;
		literal AFLOAT32 = 2;
		literal AFLOAT64 = 3;
		literal AASCIISTRING = 4;
		literal AUTF8STRING = 5;
		literal AUNICODE2STRING = 6;
		literal ABYTEFIELD = 7;
	}

Thanks,
dave

Re: [XSD2Ecore] is removing removing underscore from EEnumLiteral name and not setting literal [message #984738 is a reply to message #984678]

Wed, 14 November 2012 18:28

Eclipse User

The same problem is happening with dash separated literal names as well. In the dash case the dashes do have to be removed to make them valid Java names, but in that case the literal should have the "unaltered value of the enumeration facet" according to 9.2.2 in the EMF book, correct?

Here is a dash example:

    <xsd:simpleType name="VALID-TYPE">
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="VALID"/>
            <xsd:enumeration value="NOT-VALID"/>
            <xsd:enumeration value="NOT-DEFINED"/>
            <xsd:enumeration value="NOT-AVAILABLE"/>
        </xsd:restriction>
    </xsd:simpleType>

enum VALIDTYPE {
  VALID = 0;
  NOTVALID = 1;
  NOTDEFINED = 2;
  NOTAVAILABLE = 3;
}

Thanks,
dave

[Updated on: Wed, 14 November 2012 18:29] by Moderator

Re: [XSD2Ecore] is removing removing underscore from EEnumLiteral name and not setting literal [message #985005 is a reply to message #984678]

Wed, 14 November 2012 23:39

Eclipse User

<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
David, 
 
Comments below. 
 
<div class="moz-cite-prefix">On 14/11/2012 11:21 PM, David Rees
wrote: 
</div>
<blockquote cite="mid:k815gn$q1u$1@xxxxxxxxe.org" type="cite">I'm
running into a name mapping problem where XSD2Ecore is mapping an
Restriction with Enumeration Facets to an EENum. Each enumeration
value has an underscore, but the corresponding EEnumLiteral's name
has the underscore removed and the it's literal is not properly
set to original value either. </blockquote>
No, the literal is set properly. 
 
/** 
 * The 'AFLOAT' literal
value. 
 *  
 * 
 * If the meaning of
'AFLOAT' literal object
isn't clear, 
 * there really should be more of a description here... 
 * 
 *  
 * @see #AFLOAT 
 * @model literal="A_FLOAT" 
 * @generated 
 * @ordered 
 */ 
public static final int AFLOAT_VALUE = 0; 
 
<blockquote cite="mid:k815gn$q1u$1@xxxxxxxxe.org" type="cite">I'll
add I don't think removing the underscore should be required to
make it a valid Java name anyway.
 
</blockquote>
Technically the name is valid as long as it doesn't contain
characters that aren't valid Java characters and NCName allows many
such characters. But in general we convert names to use Camel
casee... 
<blockquote cite="mid:k815gn$q1u$1@xxxxxxxxe.org" type="cite">
 
Is this a bug or am I missing an option somewhere?
 
</blockquote>
That's just how it works. You can use Ecore annotations to specify
exactly the name you want. 
<blockquote cite="mid:k815gn$q1u$1@xxxxxxxxe.org" type="cite">
 
Thanks,
 
dave
 
 
Here is the XSD snippet:
 
 
 <xsd:simpleType name="DATA-TYPE">
 
 <xsd:restriction base="xsd:string">
 
 <xsd:enumeration value="A_INT32"/>
 
 <xsd:enumeration value="A_UINT32"/>
 
 <xsd:enumeration value="A_FLOAT32"/>
 
 <xsd:enumeration value="A_FLOAT64"/>
 
 <xsd:enumeration value="A_ASCIISTRING"/>
 
 <xsd:enumeration value="A_UTF8STRING"/>
 
 <xsd:enumeration value="A_UNICODE2STRING"/>
 
 <xsd:enumeration value="A_BYTEFIELD"/>
 
 </xsd:restriction>
 
 </xsd:simpleType>
 
 
 
And here is generated Ecore (in OCLinEcore):
 
 
 enum DATATYPE { serializable }
 
 {
 
 annotation
_'<a class="moz-txt-link-freetext" href="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">http:///org/eclipse/emf/ecore/util/ExtendedMetaData</a>'
 
 (
 
 name = 'DATA-TYPE'
 
 );
 
 literal AINT32;
 
 literal AUINT32 = 1;
 
 literal AFLOAT32 = 2;
 
 literal AFLOAT64 = 3;
 
 literal AASCIISTRING = 4;
 
 literal AUTF8STRING = 5;
 
 literal AUNICODE2STRING = 6;
 
 literal ABYTEFIELD = 7;
 
 }
 
 
</blockquote>
It looks like they're not converting the literal value. 
<blockquote cite="mid:k815gn$q1u$1@xxxxxxxxe.org" type="cite">
 
Thanks,
 
dave
 
</blockquote>
 
</body>
</html>

Previous Topic:	Problem referencing another emf project
Next Topic:	[CDO] CDOAdmin - NullPointerException on Server side using TCP connector

Goto Forum:

-=] Back to Top [=-

Current Time: Wed Jul 23 14:27:45 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter