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.
Customizations are scoped as described in Section 6.4.1, "Scope"
of the JAXB specification. A scope of a customization is the set
of schema elements to which a customization applies.
A customization can have four different scopes:
component scope, definition scope, schema scope and global scope.
For example, <property> declaration on a global attribute is
considered to have definition scope and thus applies to all
references to the global attribute.
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.
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.
--
Sekhar Vajjhala