Unmarshalling fails if substitution groups used in schema.

I think I have identified two areas within Castor that need a cleanup. I think I should be able to come up with a small work-around by tomorrow, hoping that this is actually possible for you, and have a final solution ready within a few days. The problems are related to namespace use (oddly enough, as the test case I have been using during development are fairly complicated), and the sequence order validation in the context of substitution groups.

Well, here's the work around(s):

• Can you change the namespace declaration

xmlns:po="http://xmlbeans.apache.org/samples/substitutiongroup/easypo"

to

xmlns="http://xmlbeans.apache.org/samples/substitutiongroup/easypo"

for the time being, and enable lenient sequence order check for the time being (in a custom castor.properties file), whilst we look at the underlying problems ?

And I just noticed that substitution groups with simple types (e.g. xs:string) are still not supported currently (actually never have been).

I have been able to attach patches to both sub-tasks. With these patches integrated, I am now able to deal with your sample XML schema and XML document instance provided that I exclude the 'comment' subsitution groups from scope.

Ted, just committed patches for the two sub-tasks I created a few hours ago. Which removes some of the problems, but not all of them. Right now, there's no easy way to provide you with a solution/work-around for the <comment> substitutes. The problem is that Castor - by definition - does not create classes for simple types and global elements based upon a simple type. Changing this global strategy will not be easy .. and will require us to think about a few things before going about a potential change.

Having said that, I'd still appreciate any feedback re: my comments and the patches just submitted.

Ted, when I refer to the term 'simple type', it actually does not make a difference whether I am talking about a global element definition such as

<element name="comment" type="xs:string" abstract="true" />

or

<element name="comment" type="xs:simpleString" abstract="true" />

where 'simpleString' is a simple type definition (that for example restricts xs:string). In both cases Castor will not create a separate class for the global element 'comment'. As such, Castor's current behaviour re: class generation for simple types sort of contradicts the requirements to actually create a class if a substitutionGroup attribute is involved.

It looks like we will have to change Castor in this case, but having looked at the sources, I tend to believe that this is not going to be an easy change.