Sekhar Vajjhala wrote:
>
> Mark Brouwer wrote:
> >
> > With the implementation of the external binding declaration based on
> > XPath, I thought "that is cool, I can do my multiple name conflict
> > customizations (like rename Class to ClassName) in one single step".
> > However it appears an XPath expression may only resolve to one node:
> >
> > <bindings node="//xsd:attribute[@name='class']">
> > <property name="className"/>
> > </bindings>
> >
> > Is there a reasons for this, for it would be nice to apply a
> > transformation on multiple nodes at once. I can see you can have some
> > precedence problems, but nothing that can't be solved I guess.
> > --
> > Mark Brouwer
>
> Thanks for your feedback.
>
> This is a followup to Kohsuke's response.
>
> Here is the reason why XPath expression can only resolve to one
> node.
>
>
> It is scope - not XPath - that determines all the schema
> elements to which a customization applies.
> XPath is used as a way to identify the schema element to which
> customization is attached. When inline annotation is used,
> a customization is attached at each desired schema element
> in the schema. When external binding declaration is used,
> a customization is specified for each schema element just like
> in the inline annotation case, except that the
> schema element is identified using XPath. From this
> perspective, requiring XPath expression evaluation to result
> in a single node didn't seem limiting.
>
OK, I understand your point. However with a little-bit of fantasy I
don't see a problem why an external binding can't have the feature of
allowing an XPath expression evaluation to result in multiple nodes,
just to save you from typing the same thing for multiple nodes.
I'm afraid the only use case I can come up with is name translations
like 'class' into 'className'. In my current external binding
declaration I have to write:
<bindings
node="//xsd:complexType[@name='service-def']/xsd:attribute[@name='class']">
<property name="className"/>
</bindings>
<bindings
node="//xsd:complexType[@name='principal']/xsd:attribute[@name='class']">
<property name="className"/>
</bindings>
<bindings
node="//xsd:complexType[@name='permission']/xsd:attribute[@name='class']">
<property name="className"/>
</bindings>
While the XML below could have done the same trick with less typing.
<bindings node="//xsd:attribute[@name='class']">
<property name="className"/>
</bindings>
>
> I am interested in getting feedback on whether the scoping
> rules are helpful in addressing your particular use case
> or not. If not, can you please provide an example from
> your use case where scoping rules are insufficient ? We
> can address this issue in a future version of the JAXB
> specification.
>
In general I have the feeling that it should be possible to perform name
transformation at the schema scope level, like is possible with the
nameXmlTransform element, but one that allows elements/attributes to be
defined by some sort of expression.
BTW when I started to work with JAXB I almost transformed each attribute
name that was of a collection type into the plural form (in XML it is
common to use the singular form). But as my binding declaration became
larger than my DTDs (JAXB EA) and Schemas, I stopped with that. Also
with a decent editor you can see the return type easier than in the
past, and therefore the need is less. However, I can imagine that this
could also be automated by declaring something like, foregive me for the
names I came up with:
<collectionAttributeNameXmlTransform>
<xmlName names="class,grant,permission"/>
<javaName names="classes,grants,permissions"/>
</collectionAttributeNameXmlTransform>
Hope this makes things clear.
--
Mark Brouwer