MORE QUESTIONS: copy of JMI extents

Some StructRef related questions emerging from my work on a JMI copy
operation:

When I copy from one RefPackage A to another RefPackage B both, A and B
may be from different repositories or even from different JMI
implementations.

My problem is the creation of RefStruct's in B being copies of
RefStruct's in A. My questions are more related to understanding the
specs than being really an implementation problem, which actually is
solved.

Currently I assume, that I must find a proxy in or "near by" B to
create the RefStruct value. But the JMI/MOF specs do not say anything
about this, do they ? So probably I could just take the RefStruct as
provided by A and use it in B, provided that it does not contain any
unresolved references to instance objects.

If the RefStruct from A does contain references to instance objects,
I'm even in the best case forced to recreate the RefStruct to use it
in B, because I must exchange A's instances with B's instances. But I
wonder if I probably could use a proxy from A to create the new
RefStruct ?

Is anything said in the specs about the compatibility of RefStruct's
across JMI repositories and implementations ? For values of
CollectionType, it's clear: they are arbitrary Java collections, hence
compatible. The same probably is true for values of PrimitiveType and
EnumerationType. Therefore I think values of StructureType should be
compatible similarly. But if so, I cannot understand why the specs
provide specific factory methods in the model, which in some cases may
be hidden anywhere in the vastnesses of my repository, very hard to
find.

Summarizing:

1) Can I reuse StructRef's created in one JMI repository/implementation
   in another one ?
2) Is there any clarification concerning this point in the JMI/MOF specs ?
   If not, shouldn't it be added ?
3) Was is really a good design decision, to put the factory methods for
   StructRef's into the proxies ? At least if StructRef's are deemed to
   be compatibel across JMI repositories/implementations I cannot understand
   quite well, why it was made so ugly difficult to create them. What would
   be the alternatives ?

-- 
Holger Krug
[email protected]