ComponentProvider.generateUniqueName() could cause problems when multiple providers are aggregated

[GoogleCodeExporter]

The genesis of this issue is that a downstream processor may wish to have 
multiple conflicting schemas available (for instance, revision 1.1 and 1.2 of 
something). This is not currently possible, and isn't particularly reasonable. 
It's up to the application to disambiguate; we don't have the context, and the 
problem of "context" does not have a general solution, only specific 
ones--supplied by the processor or application that can interpret the context.

However, it is perfectly reasonable for that processor or application to take 
advantage of the ability to have multiple Schema instances around, in order to 
partition the space, and then to aggregate those things in a delegating 
ComponentProvider implementation.  Here, the limitations of the current 
contract for ComponentProvider.generateUniqueName() become painful. The 
contract specifies that the name will be unique within that provider. The 
implementations make use of this to do a very simple form of generation: a 
standard namespace and name with a monotonically incrementing (per instance) 
integer. Given multiple ComponentProviders, name collisions are guaranteed when 
this method is called in two different providers.

Solution: change the contract. The method is of interest solely to provide 
unique names for anonymous types. These anonymous types appear solely in the 
context of elements or attributes. Therefore, let us add a QName argument (or 
String namespace, String name) argument (s) to the method, and supply the most 
recent element (or attribute? more study needed) name (and perhaps also the 
target namespace, for those cases when an element is in the null/global 
namespace).

Original issue reported on code.google.com by aale...@gmail.com on 15 Jun 2012 at 3:36

[GoogleCodeExporter]

A problem. We have possible solutions; this one shouldn't continue past the 
release of 1.0

Original comment by aale...@gmail.com on 26 Jul 2012 at 7:33

• Added labels: Milestone-Release1.0

[GoogleCodeExporter]

This should probably happen pretty soon, as we're seeing some interest in 
adoption of schema stuff, and that interest seems to include a notion of 
'caching'.

Ideally, we would be able to pass (parsed) schema components from context to 
context, using ComponentBag and register(ComponentBag). That can't be done 
while all anonymous types are named in a single namespace and using a single 
name-stem with a counter that monotonically increases within each naming 
authority. False positives and false negatives for matching component 
definitions (and matching type annotations on an instance) will abound.

Original comment by aale...@gmail.com on 9 Aug 2012 at 3:32

[GoogleCodeExporter]

We're handling this, now, by the ability to pass an entire SchemaComponentCache 
from TypedContext to TypedContext. So ... won't fix, because a different 
solution exists, by approaching the problem from a different direction.

Original comment by aale...@gmail.com on 24 Oct 2013 at 5:21

• Changed state: WontFix