[xsd-users] copying IDREF elements classes

[Omkar Wagh]

Hi
I suppose if there now were a way to "unset" the container once the job 
of the temporary is done, that
too might work.

Omkar

On 06/21/2012 12:22 AM, Omkar Wagh wrote:
> 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