is what I would like to replace with an extension, so that when I regenerate the stubs etc using JAX-WS, I can get access to the individual elements specified in the XSD extension (instead of having to get the request.getAny() and iterate through the nodes to get each element).
However, I would like to extend this XSD so that instead of using xs:any, I can specify my own specific elements.
I do not want to edit the same XSD but create an extension XSD that adds speeicifies the specific elements I would like to use instead of using xs:any
What you can do is to write your helper xsd's derived from the original xsd that you do not want to edit directly with the latter being included but with some re-modelling. This special kind of xs:include (preserving the same targetNamespace) is called xs:redefine. However, a jump from xs:any to xs:element of specific name living in a namespace other than the one "http://uri.abc.org/abc1234/v2.3.4#" is not a pure restriction or a pure extension. It is a mixture of both. Hence, you write first an xsd with xs:redefine referencing the original xsd via schemaLocation attribute.This xs:redefine takes out xs:any in the type mss:MRegReqType (using xs:restriction). And then you write a second helper xsd with xs:define, this time referencing the newly written xsd as mentioned above. The final xsd's xs:redefine will then use an xs:extension to insert the desired xs:element of its namespace (other than the one prefixed with mss in your code). That is the layout of how it is provisioned and allowed by the w3c schema's grand design conception.