[xsd-users] copying IDREF elements classes

[Omkar Wagh]

Hi Boris.
I think I missed out the xsd-users mailing list in my last email so 
please bear with the repeat email and you can
safely ignore the previous one.

I'm still having some issues (seg faults to be precise) in certain 
specific cases.

<xs:complexType name="some_unit">
<xs:sequence>
<xs:element name="param1" type="xs:string" />
</xs:sequence>
<xs:attribute name="my_id" type="xs:ID" />
</xs:complexType>

<xs:complexType name="some_bigger_unit">
<xs:sequence>
<xs:element name="param2" type="xs:string" />
<xs:element name="unit1" type="xs:IDREF" xse:refType="some_unit" />
</xs:sequence>
</xs:complexType>

<xs:complexType name="even_bigger_unit">
<xs:sequence>
<xs:element name="param3" type="xs:string" />
<xs:element name="unit2" type="xs:IDREF" xse:refType="some_bigger_unit" />
</xs:sequence>
</xs:complexType>

Now, say I have the following in my xml :-
<some_unit my_id="1"><param1>1</param1></some_unit>

<some_bigger_unit 
my_id="2"><param2>45</param2><unit1>1</unit1></some_bigger_unit>

<even_bigger_unit 
my_id="3"><param3>stop</param3><unit2>2</unit2></even_bigger_unit>

Now, if I try to make a copy of some_bigger_unit, then unit1 in the copy 
no longer points to any element.
This, as you pointed out, can be solved by using _container function.

Now, if I try to access an even_bigger_unit that points to the say 
some_bigger_unit with ID="2", then it
would run into a problem because now there are two some_bigger_units 
with the same ID within the
same container and it seg faults.

I'm using a simple hack wherein I change the ID of the newly created 
some_bigger_unit but it's certainly not
the kind of clean solution I'd like.

Is there any other way to do this? Or is the so called "hack" actually 
the clean solution?

Omkar

On 06/06/2012 03:20 AM, Boris Kolpackov wrote:
> Hi Omkar,
>
> Omkar Wagh<owagh at tower-research.com>  writes:
>
>> Is there any chance of this becoming an officially supported/documented
>> function sometime in the near future? I don't want to use it unless I
>> know it is stable and supported.
> I don't see this function going away. However, seeing that it is not
> expected to be used directly (you are the first person finding it useful),
> I think our time is better spend elsewhere rather than documenting its
> requirements, etc.
>
> Boris