Kohsuke Kawaguchi wrote:
> Kohsuke Kawaguchi wrote:
>
>> My apologies. It's a failed to fix to bug 6305224.
>>
>> Fixing this as we speak ...
>
>
> Sorry, no, this isn't a failed fix. Looks like this schema is
> problematic indeed. It's defining all sorts of elements that only
> differ in upper/lower cases.
>
>>> It seems as if the declaration of "graphStyle" and "GraphStyle" as
>>> element-names cause the problem. Is there a way to solve this
>>> problem without changing the schemas?
>>
The XML name to Java identifier transformation algorithm produces names
that follow Java naming
conventions. In the case of "graphStyle", the algorithm is using camel
case to concatenate
element instance factory method prefix and the element's name graphStyle..
>
> Good question. I suppose one way is to put <jaxb:class> for some of
> those elements, but I can't think of any other way.
I think adding <jaxb:class> would cause the element to be mapped to a
class, probably more than is needed.
Given that the collisions are between element instance factory methods
in ObjectFactory, it would
be ideal if placing the schema annotation <jaxb:property> on element
graphStyle could resolve the collision.
The customization is not currently specified to work this way, but I
would propose that this be the way to fix this one.
Looking at the schema, it looks like "graphStyle" could be renamed to
the more descriptive "GraphStyleProperty".
The JAXB sample fix-collides illustrates how to customize names when
collisions occurred. However, it does not
have one for this case.
We did discuss in the JAXB EG that if a name transformation caused a
collision, whether the transformation should be
dropped. For predictability and stability of the transformation
algorithm, we decided not to automate that correction but require user
to provide semantically meaningful name for the collision. Ideally, a
tool would detect the collision and generate the appriopriate
JAXB customization to resolve the collision, allowing the tool vendor to
figure out an automated name collision resolution rather
than trying to spec one.
-Joe
>
> I'll forward this to Joe and let's see what he has to say about this...
>
>