Czy parsery XML wskazują różnicę między xsi: nil = "true" a pominiętymi elementami?

Question

Czy parsery/deserializatory XML ogólnie są w stanie odróżnić nillable elements explicitly set to null and optional elements that are left out?

Załóżmy, że mamy następujące typu złożonego:

<complexType name="NiceType"> 
    <sequence> 
    <element name="niceElem" nillable="true" type="int" minOccurs="0" /> 
    </sequence> 
</complexType> 

element jednoznacznie wartość zerową (przykład 1):

<niceType> 
    <niceElem xsi:nil="true"/> 
</niceType> 

element pominięty (przykład 2):

<niceType> 
</niceType> 

Czy parsery w ogóle, takie jak implementacje JAX-B lub .NET alikes, takie jak moduł XML WCF, będą w stanie powiedzieć różnica między przykładem 1 i przykładem 2 powyżej? Innymi słowy, czy w sposób umożliwiający współdziałanie byłby w stanie połączyć obydwie reprezentacje NULL - jak w przykładzie - w celu przekazania różnych odcieni NULL?

Answer 1

parser XML (np XmlReader, XmlDocument, XDocument) nie traktują xsi:nil specjalnie - jeszcze zobaczyć element w strumieniu/dokumentu.

XmlSerializer obsługuje xsi:nil: w tym kontekście oznacza to samo co pominięty węzeł; możesz dokonać serializacji WCF przy użyciu XmlSerializer przez oznaczenie swoich DataContract s przy użyciu XmlSerializerFormatterAttribute.

DataContractSerializer używa tego atrybutu: nie jestem jednak pewien, jakie są wszystkie reguły, aby je wykorzystać (jeden przypadek to circular references) - jest znacznie bardziej prawdopodobne, aby pominąć elementy. Nie sądzę, że powinieneś przekazać xsi:nil do DataContractSerializer, chyba że używa go w tym przypadku - ponieważ DataContractSerializer jest zaprojektowany wokół założeń, aby poprawić wydajność de/serializacji.

Z spec wygląda jakby został pierwotnie zaprojektowany do pracy jak i JavaScript nullundefined - gdzie null (xsi:nil) jest niepoprawna i undefined (pominięty) jest cały nieistnienie wartości; szczególnie w przypadku typów złożonych - możesz podać element, ale pominąć jego zawartość (nawet jeśli zawartość jest wymagana zgodnie ze schematem).

Generalnie powinienem tego unikać. Jest nieintuicyjny - wydaje mi się, że nie widziałem interfejsu REST/SOAP API, który go używa (oprócz programu InfoPath, który używa go wyłącznie); najczęściej wystarczy użyć null = undefined. Deklaracja xmlns i jej użycie również pochłaniają kilka dodatkowych wartościowych bajtów.

towarowe Bonus: Jeśli się elementem opcjonalnym i nie ma pustych (np xsd:int) the # generator C stanowi własność <Name>Specified - można dodawać własne właściwości jak ten. Umożliwiłoby to rozróżnienie między xsi:nil a omittance (zero, gdy określono i null, pominięte, gdy nie zostało określone). Działa to jednak tylko z XmlSerializer.