> And of course what you are doing is also reasonably common.
>
> What I'm saying is that just supporting your use case would put us into
> a difficult position of explaining why we can do it for you but not for
> all the other people who have similar but different needs (whereas our
> current position is quite easily justifiable --- we support XML ID/IDREF
> semantics.)
Well, my approach to these types of situations in a framework system
would be to make my framework flexible enough to deal with as many of
the known use-cases as possible. Typically, this can be done by
allowing the user of the framework (in this case JAXB) to override
particular behaviors in the interface.
For example, in JAXB the ID storing and resolution could be centralized
into an IDResolver interface. The RI would then provide the default XML
ID/IDREF implementation, but the user could override that to support any
ID resolution strategy. The trick is providing the IDResolver with the
information necessary to perform several types of ID resolution, not
just the default strategy.
So, for example if the IDResolver interface looked like:
public interface IDResolver {
public bind( String id, Object obj );
public resolve( String id, Class targetType );
}
the resolve method obviously does not need the "targetType" for a
default XML ID/IDREF implementation, but DOES need it for the strategy I
discussed (which you admitted is common). Also, you may want to pass
additional arguments such as namespace, etc. to help with
implementations that want to support a scoped resolution strategy.
I definitely don't think that a standard specification should support
any one strategy, nor do I think it should attempt to support all
strategies. However, if it doesn't provide some way to override
behavior for use-cases that are known to be common - people are going to
abandon the spec and either write their own home grown solution or find
another alternative. I'd much prefer to have a flexible JAXB
implementation that supported the needs of as many people as possible to
foster its adoption and usefulness.
Jeremy