That can happen (to wsdl2jave, in particular, or possibly to whatever code-generation tools) usually if your local element(s) is in some namespace(s) other than the global element containing it and that, in consequence, your xsd contains also xs:import element for instance... The code-generation engine may thereby consider annotating the package with QUALIFIED be more convenient in those cases...
But, at the end, the apparent non-honouring of elementFormDefault in the package-info should not be a cause of failure of validating or unmarshalling the xml that is constructed with xsd as its blueprint. What I mean is also that you have to, if in doubt, first of all, validate the xml from within the xml-xsd line as the test before looking into what might be wrong in the data binding. Also looking from xml-xsd-centric angle, the elementFormDefault unqualified in the xsd can always be rewritten in an equivalent form with an xsd combination all with elementFormDefault scripted as qualified instead.
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop