You can create the same elements under different node in XSD and there after schema can be created in developer using that XSD. But in the XSD structure that you have provided, I couldn’t able to see the seperate parent node for the elements a, b and b,a,c. Can you briefly explain me your requirement.
For Example conside a message with header and detail segment sharing some of the common fields between them. In, such cases it is possible to define a XSD with all field and then referring the required fields in header and detail segment. But, in your case how you are defining the elements a,b and c and how you are referring into the main node TEST in XSD?
I don’t think it’s a bug per se. But it’s definitely a limitation. The documentToXMLString service uses the doc type to order the elements. One approach is to define 2 doc types, one with A, B order the other with B, A, C. Then in the service determine which doc type to use in the call to documentToXMLString. Not pretty but should work.
The XSD is provided by the partner. I just give an .xsd example with the problem I have with a bigger one (the original).
The requirement in my example was to handle xml with “a” and “b” tag under the “TEST” tag, but also “b”, “a”, “c”. But If you import this XSD you can’t generate both cases.
So I have to modify the XSD to import the docType or modify manually the docType.
The thing you may want to confirm with the partner: “is order of the elements important?” Usually it is not. And can be a challenge since XML itself does not provide any constraints on element order–order has to be checked verified with something else, such as XML schema. Since IS doesn’t use XML schema to create or parse (it uses its own related variation, IS schema) it can present challenges when different orders are needed.