First thing first. The complexType personType is capable of validating both messages with root element person. That is the meaning I can deduce from the original question.
Now we are told that the two messages each has a different meaning, one for create, one for update and each requires the absence and the presence of the id element with rigidity. That would then be a functional meaning put on top. And sure we have to deal with it one way or another.
There are several possible routes to take.
[1] You could put up seperate namespace of the person element. One for create, such as urn:xyz:create or
http://xyz/create or else. One for urn:xyz:update or
http://xyz/update or else. For each namespace, you've a separate schema (file). You can even setup a single container schema with at least that two xs:import to import those two schemas into a single schema for convenient management.
In this case, you would have each element definition such as
tns:personType, with tns being the prefix for the distinct targetNamespace, one with element id, one without.
However, when sending the request message, inevitably, your person element must have a namespace attached to.
[2] However, sometimes, a (
soap) message in the body, people might just elect to have that without a namespace. In that case, it would be hard press to have two schemas of null targetNamespace with both person elements defined. In that case, you can do this.
In the schema, you define only complexType without defining or leaving out the definition of the person element.
Then in the message, you set the person element up by adding a schema-related markup xsi:type (xsi being the prefix for XMLSchema-instance namespace), like this.
or
according to the message nature.
Which approach, and variations of it, be more attractive, it is up to each one's taste and the convenience of the concrete need and the chain of dispatchments one has to face. But, the big picture is something like what is described above.
