Yes it is a typo / should not be there.
In that case, the following xs:complexType etc are still incompatible with the existence of @type="typer:cccc". Having that posted will confuse further readers. It is still incorrect, but I leave you to sort it out as I suspect you've a better blueprint and valid schema behind the screen.
right now this code ggg that reference to the typer'GGG':
<xs:simpleType name="GGG">
<xs:restriction base="xs:unsignedShort"/>
</xs:simpleType>
generates java:
The code generated will deliver as far as the idea of "required = true" is concerned for a subtle reason. The xs:unsignedShort would be mapped to java type "int". Now, int is an atomic value type, and it is implicitly initialized to 0. It would never ever be null as any other object types. When jaxb marshalling the object graph, the element, say ns:x, having the type GGG will always be outputted. If you haven't assign any value to it, it will output <ns:x>0</ns:x>. This you can verify it with your existing code already. There won't be any circumstance where the output would miss out the element ns:x. This is essentially what you wish to have. That means even by default required being false, the practical result will be exactly footing the bill as if required = true.
Now, what if you ask that you want at all cost having the required being true explicitly. You can do it like this.
The magic here is that xs:integer would be mapped to java.math.BigInteger. Without assigning it a value, it would be null and resulting in jaxb engine not marshalling it out, hence, an invalid document being outputted. Hence, the required will be enforced somehow via the ObjectFactory and some other locations in the code probably...
Again, all these can be verified a posteriori if you run the code.