sind diese beiden XMLs gleich?

Was Ihre zweite letzte Frage betrifft: Diese XML-Dateien können nicht als gleich angesehen werden. Hier ist warum:

1. Die Namespaces für die Elemente SomeID und SomeStatus sind nicht identisch. In der Delphi-XML wird im XML-Code niemals ein Standardnamespace angegeben. Wir sehen nur die folgenden Namespaces:

   • xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
   • xmlns:xsd="http://www.w3.org/2001/XMLSchema"
   • xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   • xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
   • xmlns:NS2="http://tempuri.org/"
   • xmlns:NS1="http://tempuri.org/"

   Somit befinden sich die Elemente SomeID und SomeStatus in keinem Namespace, da ihnen ein Namespacepräfix fehlt.

   Umgekehrt hat der XML-Code aus der c # -App die folgenden Namespaces

   • xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
   • xmlns="http://tempuri.org/"

   Wie Sie sehen, ist das zweite xmlns -Attribut ein Standard-Namespace-Attribut, also befinden sich die untergeordneten Elemente SomeID und SomeStatus im " Ссылка "Namensraum. Dies bedeutet, dass diese Elemente unterschiedliche qualifizierte Namen haben und somit nicht gleichwertig sind.

   (Wenn ich raten müsste, würde ich annehmen, dass das c # XML korrekt ist und das Delphi XML einen Fehler hat. Aber ich kann es nicht sagen seit dem XSD für den SOAP-Standard , auf den Sie verweisen, hat kein bestimmtes Schema für Body .

2. Das XML von Delphi enthält zusätzliche Informationen zum Typ von SomeID und SOME_OK_STATUS . Dies kann für Empfänger nützlich sein, da der SOAP-Standard "keine bestimmte Struktur oder Interpretation dieser Elemente vorschreibt, und bietet kein Standard-Mittel zum Festlegen der durchzuführenden Verarbeitung "für Elemente in Body . Wenn der Empfänger jedoch bereits weiß, was in diesen Elementen zu erwarten ist, können diese Attribute unnötig sein.

Dies sind die wichtigsten logischen Unterschiede zwischen den XML-Beispielen, die ich sehe.

Was die erste letzte Frage betrifft, müssten wir den c # -Code sehen, um definitiv zu erklären, warum das XML, das er erzeugt, so aussieht. Wenn XmlSerializer für die Serialisierung verwendet wurde, wird xsi:type für nicht polymorphe Felder nicht ausgegeben, es sei denn dazu gezwungen

1 - Wie Sie angegeben haben, ist UTF-8 Standard und kann daher weggelassen werden

2 - s und SOAP-ENV beziehen sich auf die Objekte desselben Typs, die durch Bezugnahme auf denselben Namespace angegeben wurden - Ссылка . Sie können dem Link folgen, um das Schema des Objekts zu sehen. Dies bedeutet, dass sowohl s als auch SOAP-ENV Objekte vom Typ Envelope sind, wie im Schema

3 - das Definieren des Objekttyps von SomeTagName ist optional, da es anderswo nicht referenziert wird, wie es bei dem Objekt Envelope der Fall ist, auf das in der Deklaration von Body verwiesen wird definiertes Lesen geben Sie ihm einen Namen, da es wirklich durch den Namensraum definiert ist). So wird NS1 in einem, aber nicht in dem anderen mit einem beliebigen Namen deklariert. Nur der Namespace ist in diesem Fall erforderlich und beide haben es.

4 - Der andere Unterschied, den ich sehe, ist, dass die Delphi-Version den Namespace von nicht komplexen Typen (wie xsd:int ) festlegt. Dies ist wiederum optional, da dies im Schema festgelegt ist, das sollte dies regeln. Wenn das Schema auf einen Typ und die Anfrage / Antwort auf einen anderen verweist, haben wir ein Problem.

Das Einzige, was diese beiden Unterschiede macht, ist, dass die Payload auf der Delphi-Version bei großen Anfragen / Antworten, die mit mobilen Geräten in Frage kommen, viel größer ist