Name mangling in the SDO JavaGenerator

[James M Snell <ja...@gmail.com>]

Hey all,

Following on to the changes Frank and I made to the SDO impl's handling
of names in the model, the JavaGenerator was put into a state in which
XML Schemas that were not properly annotated with sdo:name attributes
could produce Java classes that would not compile.  For example, strip
the sdo:name attributes from the sca.core.xsd file and you'll note a
number of compile issues with improper Java identifiers.

While the correct solution around such problems is the inclusion of
sdo:name annotations, I have modified JavaGenerator so that it will
generate compilable code.

The issue is the form of the java identifiers produced.  Right now the
algorithm that I'm using to generate the safe names is pretty simple...
just replace all of the illegal characters in the name with an
underscore.  e.g. source.uri becomes source_uri.  While this works, it
produces a strange looking API.. e.g. getSource_uri, setSource_uri, etc.
 Another example shows up in the sca.core.xsd's Multiplicity enum, in
which enum options like 1..n are transformed into _1__n.  Obviously,
this is nasty, but it works, and given that the ultimately correct
solution is the use of sdo:name, this *might* be a decent fallback (at
the very least, if folks complain about the nasty looking generated
names, we can point them to sdo:name as a way of creating the really
nice looking names they want to see).

Alternatively, I could modify the algorithm to produce prettier names,
like "sourceUri" or "_1n", etc.

Opinions?

- James Snell

Re: Name mangling in the SDO JavaGenerator

[James M Snell <ja...@gmail.com>]

Ok, I've taken a look and I have an alternative algorithm that produces
much prettier names.

e.g. source.uri from sca.core.xsd comes out as sourceUri
     1..n from sca.core.xsd's Multiplicity enum comes out as VALUE_1N

The result is closer to what JAXB produces and is much nicer overall.

- James

Daniel Kulp wrote:
> Just FYI:   the JAXB 2.0 spec contains a fairly large section on tackling 
> this issue.    It might be worth a look for ideas and maybe even doing 
> the same thing.
> 
> Dan
> 
> 
> On Wednesday 29 March 2006 11:49, James M Snell wrote:
>> Hey all,
>>
>> Following on to the changes Frank and I made to the SDO impl's handling
>> of names in the model, the JavaGenerator was put into a state in which
>> XML Schemas that were not properly annotated with sdo:name attributes
>> could produce Java classes that would not compile.  For example, strip
>> the sdo:name attributes from the sca.core.xsd file and you'll note a
>> number of compile issues with improper Java identifiers.
>>
>> While the correct solution around such problems is the inclusion of
>> sdo:name annotations, I have modified JavaGenerator so that it will
>> generate compilable code.
>>
>> The issue is the form of the java identifiers produced.  Right now the
>> algorithm that I'm using to generate the safe names is pretty simple...
>> just replace all of the illegal characters in the name with an
>> underscore.  e.g. source.uri becomes source_uri.  While this works, it
>> produces a strange looking API.. e.g. getSource_uri, setSource_uri,
>> etc. Another example shows up in the sca.core.xsd's Multiplicity enum,
>> in which enum options like 1..n are transformed into _1__n.  Obviously,
>> this is nasty, but it works, and given that the ultimately correct
>> solution is the use of sdo:name, this *might* be a decent fallback (at
>> the very least, if folks complain about the nasty looking generated
>> names, we can point them to sdo:name as a way of creating the really
>> nice looking names they want to see).
>>
>> Alternatively, I could modify the algorithm to produce prettier names,
>> like "sourceUri" or "_1n", etc.
>>
>> Opinions?
>>
>> - James Snell
> 

Re: Name mangling in the SDO JavaGenerator

[Daniel Kulp <da...@kulp.com>]

Just FYI:   the JAXB 2.0 spec contains a fairly large section on tackling 
this issue.    It might be worth a look for ideas and maybe even doing 
the same thing.

Dan


On Wednesday 29 March 2006 11:49, James M Snell wrote:
> Hey all,
>
> Following on to the changes Frank and I made to the SDO impl's handling
> of names in the model, the JavaGenerator was put into a state in which
> XML Schemas that were not properly annotated with sdo:name attributes
> could produce Java classes that would not compile.  For example, strip
> the sdo:name attributes from the sca.core.xsd file and you'll note a
> number of compile issues with improper Java identifiers.
>
> While the correct solution around such problems is the inclusion of
> sdo:name annotations, I have modified JavaGenerator so that it will
> generate compilable code.
>
> The issue is the form of the java identifiers produced.  Right now the
> algorithm that I'm using to generate the safe names is pretty simple...
> just replace all of the illegal characters in the name with an
> underscore.  e.g. source.uri becomes source_uri.  While this works, it
> produces a strange looking API.. e.g. getSource_uri, setSource_uri,
> etc. Another example shows up in the sca.core.xsd's Multiplicity enum,
> in which enum options like 1..n are transformed into _1__n.  Obviously,
> this is nasty, but it works, and given that the ultimately correct
> solution is the use of sdo:name, this *might* be a decent fallback (at
> the very least, if folks complain about the nasty looking generated
> names, we can point them to sdo:name as a way of creating the really
> nice looking names they want to see).
>
> Alternatively, I could modify the algorithm to produce prettier names,
> like "sourceUri" or "_1n", etc.
>
> Opinions?
>
> - James Snell

-- 
J. Daniel Kulp
dan@kulp.com