Hi,
I originally mentioned this question in the "Best Practices for Modularity?" thread, but I am breaking it out so I can clarify my problem.
I have an element like this:
<Foo>
<Action></Action>
...
</Foo>
"Action" is a class hierarchy of different kinds of actions. I configured "Action" with an XMLChoiceMapping and inheritance hierarchy. The hierarchy has three levels like:
Action
CategoryOfAction
SpecificAction (such as Process)
In the Root Parent Descriptor for "Action", I have to specify a Class Extraction Method or Class Indicator Field. After some trial and error, it seems that I cannot use the Class Extraction Method for XML mappings (only relational ones use this). So to specify the Class Indicator Field, my choices are the XML Schema "Type" Attribute or to specify a field in the XML. There's no element in my XML doc that corresponds to the type (except the element itself like <Process>!). So I chose the option for XML Schema "Type" Attribute.
This is where the problem is. When I unmarshal the document, EclipseLink does not care that there is no "xsi:type" attribute on the "Process" element, and everything works great. But when I marshall it back out, the Action element is output with the attribute 'xsi:type="ns1:ProcessType"'. Then when I unmarshall the document again, I get:
[Fatal Error] :178:72: The prefix "xsi" for attribute "xsi:type" associated with an element type "ns1:Process" is not bound.
I know this is because the the "xsi" namespace is not defined. But I don't want to fix this problem by adding the namespace. The "xsi:type" attribute is not allowed in our schema, and we'd like to not have to add it. How can I prevent the xsi:type attribute from being generated? Is there another way I can specify inheritance without using it at all? EclipseLink really doesn't seem to need it for unmarshalling.
Thanks,
Polly
