Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [XSD] Change identifier/property mapping
[XSD] Change identifier/property mapping [message #919306] Fri, 21 September 2012 18:15 Go to next message
David Rees is currently offline David Rees
Messages: 47
Registered: September 2012
Member
Is there a way to change how XSD names (like class and property) are mapped to Ecore?

For properties it seems to be forcing the first character to be lowercase even though that its not an Ecore/Java restriction. Its even ignoring when I try to use ecore:name to override it in the XSD. For example this
           <xsd:element type="xsd:string" name="MYNAME" ecore:name="MYNAME" />

is currently becoming the following, but I would like it to stay MYNAME.
		attribute mYNAME : _'ecore.xml.type'::String { ordered }
		{
			annotation _'http:///org/eclipse/emf/ecore/util/ExtendedMetaData'
			(
				kind = 'element',
				name = 'MYNAME',
				namespace = '##targetNamespace'
			);
		}


I also would like to change class/property name mapping to replaces dashes with underscores rather than just eliminating the dashes (so A-NAME becomes A_NAME rather than ANAME). And if I do figure out where to tweak this I also hope to look at camelcasing as well (AName).

If this isn't possible in properties can someone point me towards the right area in the source to look at tweaking things?

Thanks,
dave
Re: [XSD] Change identifier/property mapping [message #919541 is a reply to message #919306] Sat, 22 September 2012 00:19 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 25947
Registered: July 2009
Senior Member
David,

Comments below.

On 22/09/2012 12:15 AM, David Rees wrote:
> Is there a way to change how XSD names (like class and property) are
> mapped to Ecore?
With annotations in the schema.
>
> For properties it seems to be forcing the first character to be
> lowercase even though that its not an Ecore/Java restriction.
Yes, Ecore models should follow standard Java naming conventions, e.g.,
features should follow the convention for Java fields.
> Its even ignoring when I try to use ecore:name to override it in the
> XSD. For example this
> <xsd:element type="xsd:string" name="MYNAME"
> ecore:name="MYNAME" />
This really won't produce readable Java... I'd expect you'd specify
"myName" given that the proper camel case name can't be deduced from the
all-caps name.
> is currently becoming the following, but I would like it to stay MYNAME.
> attribute mYNAME : _'ecore.xml.type'::String { ordered }
> {
> annotation
> _'http:///org/eclipse/emf/ecore/util/ExtendedMetaData'
> (
> kind = 'element',
> name = 'MYNAME',
> namespace = '##targetNamespace'
> );
> }
>
> I also would like to change class/property name mapping to replaces
> dashes with underscores rather than just eliminating the dashes (so
> A-NAME becomes A_NAME rather than ANAME).
Again, you'd never expect to see such names used in Java where an
upper-case camel case is general used.
> And if I do figure out where to tweak this I also hope to look at
> camelcasing as well (AName).
Why do you hope to produce something that will generate code that looks
like something no one familiar with Java would expect to see?
>
> If this isn't possible in properties can someone point me towards the
> right area in the source to look at tweaking things?
No, you'd really need to specialize the XSDEcoreBuilder itself, i.e.,
methods like org.eclipse.xsd.ecore.NameMangler.validName(String, int,
String)

Keep in mind that the generator assumes Java conventions will be used.
Such conventions ensure that a field name never looks like a class name,
so there can never be an ambiguity if a name references refers to a
field verses a class. If you stray from such conventions, it may well
be the case that the generated code has ambiguous references.
>
> Thanks,
> dave
>
Re: [XSD] Change identifier/property mapping [message #921962 is a reply to message #919541] Mon, 24 September 2012 11:48 Go to previous messageGo to next message
David Rees is currently offline David Rees
Messages: 47
Registered: September 2012
Member
Ed Merks wrote on Sat, 22 September 2012 00:19

> Is there a way to change how XSD names (like class and property) are
> mapped to Ecore?
With annotations in the schema.


Yes, I know that "manual" approach. I was hoping for a way of substituting my own mapping generator rather than having add ecore:name on every type in my XSD. You point me in the right direction below, thanks.

Ed Merks wrote on Sat, 22 September 2012 00:19

Yes, Ecore models should follow standard Java naming conventions, e.g.,
features should follow the convention for Java fields.

Why do you hope to produce something that will generate code that looks
like something no one familiar with Java would expect to see?


To be honest, we are not really worried about "readable" Java or Java at all. I understand EMF's roots are in Java code generation, but, as I'm sure you know, its used for much more these days (both use cases and languages).

In our case we are using the Ecore model for mapping between different models. The XSD is from an ISO standard. With that in mind I want the Ecore model to map as closely to the names in the specification so the users can quickly jump between spec and EMF. As you probably know all caps is pretty common in the XML world (even if it is ugly :).

I understand dashes are illegal in Ecore and Java, but lowercase attributes are only a convention in Java and not required. The same is true for underscores. It does sound like there is another gotcha you list below.

As an aside, I personally think it would be better if Ecore was more flexible in naming than Java (e.g. allowing dashes) to provide more flexibility in modeling. Then language mappings could deal with each language's restrictions and each project's conventions.


Ed Merks wrote on Sat, 22 September 2012 00:19

> If this isn't possible in properties can someone point me towards the
> right area in the source to look at tweaking things?
No, you'd really need to specialize the XSDEcoreBuilder itself, i.e.,
methods like org.eclipse.xsd.ecore.NameMangler.validName(String, int,
String)


Thanks, that is the hint I was looking for :).

Ed Merks wrote on Sat, 22 September 2012 00:19

Keep in mind that the generator assumes Java conventions will be used.
Such conventions ensure that a field name never looks like a class name,
so there can never be an ambiguity if a name references refers to a
field verses a class. If you stray from such conventions, it may well
be the case that the generated code has ambiguous references.


Thanks, that is a good gotcha to be aware of. To be clear, are you talking about the Ecore/Java generation for import/export? And you are saying it doesn't check for duplicates across the classes and attributes?

Thanks for your help. It gives me good context for figuring out the best way to map this for the users.

dave
Re: [XSD] Change identifier/property mapping [message #921979 is a reply to message #921962] Mon, 24 September 2012 12:03 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 25947
Registered: July 2009
Senior Member
David,

Comments below.

On 24/09/2012 5:48 PM, David Rees wrote:
> Ed Merks wrote on Sat, 22 September 2012 00:19
>> > Is there a way to change how XSD names (like class and property)
>> are > mapped to Ecore?
>> With annotations in the schema.
>
>
> Yes, I know that "manual" approach. I was hoping for a way of
> substituting my own mapping generator rather than having add
> ecore:name on every type in my XSD. You point me in the right
> direction below, thanks.
> Ed Merks wrote on Sat, 22 September 2012 00:19
>> Yes, Ecore models should follow standard Java naming conventions,
>> e.g., features should follow the convention for Java fields.
>>
>> Why do you hope to produce something that will generate code that
>> looks like something no one familiar with Java would expect to see?
>
>
> To be honest, we are not really worried about "readable" Java or Java
> at all. I understand EMF's roots are in Java code generation, but, as
> I'm sure you know, its used for much more these days (both use cases
> and languages).
Maybe you don't need a generated model at all then?
>
> In our case we are using the Ecore model for mapping between different
> models. The XSD is from an ISO standard. With that in mind I want the
> Ecore model to map as closely to the names in the specification so the
> users can quickly jump between spec and EMF. As you probably know all
> caps is pretty common in the XML world (even if it is ugly :).
It fits well with XML's intrinsic ugliness. :-P
>
> I understand dashes are illegal in Ecore and Java, but lowercase
> attributes are only a convention in Java and not required. The same is
> true for underscores. It does sound like there is another gotcha you
> list below.
>
> As an aside, I personally think it would be better if Ecore was more
> flexible in naming than Java (e.g. allowing dashes) to provide more
> flexibility in modeling.
Every language has its constraints on names...
> Then language mappings could deal with each language's restrictions
> and each project's conventions.
You'd end up with a lot more unobvious mappings, which is exactly your
concern here...
>
>
> Ed Merks wrote on Sat, 22 September 2012 00:19
>> > If this isn't possible in properties can someone point me towards
>> the > right area in the source to look at tweaking things?
>> No, you'd really need to specialize the XSDEcoreBuilder itself, i.e.,
>> methods like org.eclipse.xsd.ecore.NameMangler.validName(String, int,
>> String)
>
>
> Thanks, that is the hint I was looking for :).
Another approach is to post process the resulting Ecore. You can easily
get at the original XML names using ExtendedMetaData.INSTANCE.getName
and then update the name according to your own algorithms.
>
> Ed Merks wrote on Sat, 22 September 2012 00:19
>> Keep in mind that the generator assumes Java conventions will be
>> used. Such conventions ensure that a field name never looks like a
>> class name, so there can never be an ambiguity if a name references
>> refers to a field verses a class. If you stray from such
>> conventions, it may well be the case that the generated code has
>> ambiguous references.
>
>
> Thanks, that is a good gotcha to be aware of. To be clear, are you
> talking about the Ecore/Java generation for import/export?
Yes, violating Java naming conventions can cause ambiguities in the
generated code.
> And you are saying it doesn't check for duplicates across the classes
> and attributes?
If you have a generated field and a class with the same name, that's
very likely to cause problems. No checking is done for that.
>
> Thanks for your help. It gives me good context for figuring out the
> best way to map this for the users.
Perhaps better is that you provide links in the model documentation
annotations that specify the XML information. Of course it's there in
the generated @model information already...
>
> dave
Re: [XSD] Change identifier/property mapping [message #925549 is a reply to message #921979] Thu, 27 September 2012 16:47 Go to previous message
David Rees is currently offline David Rees
Messages: 47
Registered: September 2012
Member
Thanks again for all your help. I'm going to go with camelcase, no reason to swim upstream if I don't have to.

Post-processing the Ecore is a good suggestion also. Or I may use XSL, or a combination of both. Will see what ends up the "cleanest".

d
Previous Topic:[Xcore] Import metamodel by URI/path
Next Topic:Hibernate EList
Goto Forum:
  


Current Time: Thu Jul 31 19:40:58 EDT 2014

Powered by FUDForum. Page generated in 0.01709 seconds