As far as I understand, XML permits different ordering of tags, so your example is missing an attribute or element that determines what input block is matched to what response block. There are various approaches, depending on exactly what your requests and responses actually look like.
The response might be something like:
<ClientData>
<Field>
<clientID>123</clientID>
<FieldName>EmployeeNumber</FieldName>
<FieldValue>45698</FieldValue>
</Field>
</ClientData>
<ClientData>
<Field>
<clientID>456</clientID>
<FieldName>EmployeeNumber</FieldName>
<FieldValue>7896</FieldValue>
</Field>
</ClientData>
In this case, I might investigate An Approach for virtualizing optional repeating blocks
If you have a desire to make "better" XML than is provided by whatever automated process created the original XML ... by the way, I would talk to the development team, asking them to update the API, because would judge that the use of <fieldName> and <fieldValue> tags are counter-intuitive and APIs shouldn't be generated in this way ... What I have done in the past is create a scriptable DPH to change the XML to something like:
Request:
<client>
<ClientID>123</ClientID>
<Name>abcd</Name>
</client>
<client>
<ClientID>456</ClientID>
<Name>efgh</Name>
</client>
Response:
<ClientData ClientID="123">
<EmployeeNumber>45698</EmployeeNumber>
</ClientData>
<ClientData ClientID="456">
<EmployeeNumber>7896</EmployeeNumber>
</ClientData>
These blocks lose nothing of the original data, in fact they keep response blocks related to request blocks by the addition of the "ClientID" attribute, they are much more readable, and they take less space.
It could be that, if you implement a scriptable DPH to manipulate the XML to be "better", you find that the options are straightforward and you don't need to add the effort to virtualise the optional repeating blocks.
Finally, the more effort you put into doing this in DevTest, the less likely you are to want to discard your carefully-crafted virtual service when there are new & different data scenarios. If your company uses CA Test Data Manager, that is the best place to do your repeating data management, ant it can output its data scenarios to your running virtual services, at the time when the tester requests his test data in TDM Portal, enabling really complex data scenarios on demand. This would mean that you don't bother about adding this level of block data management in DevTest.