XSD更改时针对XSD验证XML

Question

Lets suppose I have an XSD schema named xsd1 . Assume that a generated class looks like

public class ClassA
{
    public string Prop1 { get; set; }
    public string Prop2 { get; set; }
}

Then I create a new schema xsd2 which is almost the same as xsd1. It has only one more element Prop3 of type int . Then ClassA changes to

public class ClassA
{
    public string Prop1 { get; set; }
    public string Prop2 { get; set; }
    public int Prop3 { get; set; }
}

Now, when I serialize an instance of ClassA to XML, validation against xsd1 fails with message

Invalid child element 'Prop3'

How can I have both validations succeed? I don't want two separate classes.

Update

Serialized object

var a = new ClassA() { Prop1 = "p1", Prop2 = "p2" };

looks like

<ClassA>
    <Prop1>p1</Prop1>
    <Prop2>p2</Prop2>
</ClassA>

when I add Prop3 to ClassA then the serialized object a becommes

<ClassA>
    <Prop1>p1</Prop1>
    <Prop2>p2</Prop2>
    <Prop3>0</Prop3>
</ClassA>

and as so not valid against schema xsd1 . When validating against xsd1 I want only Prop1 and Prop2 to be serialized.

Answer 1

Your question resembles a schema versioning question where you seek both forward and backward compatibility while adding a new element. That is simply not possible.

Adding an optional element allows XML that was valid against XSD ₁ to continue to be valid with the new version, XSD ₂ . That part is fine. However, any XML that includes the optional new element will not be valid against the original version, XSD ₁ .

Update

When I publish a new schema, clients need time to adapt their code.

Fair enough -- a common requirement.

Our clients sends us data (objects, not xml)

That's backward from recommended best practices.

they determine against which schema should it be validated

Then either honor their commitment (rather than trying to defeat it) by supporting both XSDs during transition, or build in flexibility to your XSDs via liberal mechanisms such as xsd:any . It's up to you, but you cannot expect validation be both strict and liberal simultaneously.