uso di minOccurs="0" senza nillable="true" in SOAP

Question

uso di minOccurs="0" senza nillable="true" in SOAP

#1 da (0 voti)

1

Ho ricevuto un XSD da un fornitore di terze parti generato da un sistema basato su Java; che deve essere utilizzato per creare un endpoint SOAP per consentirci di ricevere trasferimenti di dati. Il loro XSD non fa alcun uso dell'attributo nillable definito all'interno dello spazio dei nomi W3C / XSD, ad esempio:

<xs:complexType name="Customer">
    <xs:sequence>
        <xs:element minOccurs="1" maxOccurs="1" name="ID" type="xs:integer"/>
        <xs:element minOccurs="0" maxOccurs="1" name="TitleID" type="xs:integer"/>
        <xs:element minOccurs="0" maxOccurs="1" name="FirstName" type="xs:string"/>
        <xs:element minOccurs="0" maxOccurs="1" name="FamilyName" type="xs:string"/>
        <xs:element minOccurs="0" maxOccurs="1" name="PreviousName" type="xs:string"/>
        <xs:element minOccurs="0" maxOccurs="1" name="DateOfBirth" type="xs:date"/>
    </xs:sequence>
</xs:complexType>

Parlando con il fornitore è stato menzionato " where minOccurs="0" e il loro valore non è presente, gli elementi verranno omessi".

Quando usiamo lo Strumento di definizione dello schema XSD per creare classi; le classi vengono generate correttamente con 2 eccezioni: le proprietà DateOfBirth e TitleID non sono annullabili.

A meno che nillable="true" sia dichiarato all'interno dell'XSD per tipi semplici, tipi di valore o non creati come Nullable nonostante la configurazione minOccurs="0" . Dopo alcune ricerche ritengo che questa interpretazione sia corretta, date informazioni nei seguenti articoli:

Ho concluso da quanto sopra che minOccurs="0" è una definizione che afferma che l'elemento all'interno di XML è facoltativo, ma non ha alcun significato particolare. È chiaro che all'interno di un messaggio SOAP; per non comunicare alcun valore per un particolare elemento, nill="true" deve essere utilizzato all'interno di un elemento vuoto.

Presentando questo al nostro fornitore; Ho sostenuto che gli attributi nillable mancanti lasciano l'XSD ambiguo e manca di intento quando si fa riferimento agli standard, dato che omettere gli elementi non è nullo, è solo implicito. Il W3C indica se un messaggio deve indicare che un elemento è nullo, dovrebbe essere esplicitamente indicato. Il loro rappresentante non era d'accordo e sosteneva che se non ci fosse DateOfBirth (per esempio) rimuoveranno l'elemento per questo nel messaggio SOAP. Ritengono che ciò sia accettabile e conforme agli standard. Da quanto ho letto qui , minOccurs / nillable hanno lo stesso comportamento in Java (forse perché sentono che non devono usare attributi nillable)

So che posso aggirare questo, ma alla fine; esso (potenzialmente) ha un aumento significativo della quantità di codice aggiuntivo richiesto per il bene del nostro fornitore che non desidera utilizzare l'attributo nill / nillable nel messaggio XSD e SOAP. Sto costruendo la nostra API SOAP in WCF; dopo la deserializzazione dovrò controllare tutte le proprietà specificate che vengono generate per verificare la presenza di elementi mancanti. Ciò è dovuto al fatto che i tipi di valore a cui non viene fatto riferimento nel messaggio xml verranno assegnati ai relativi valori predefiniti. In alternativa, potrei passare attraverso l'XSD e aggiungerli da solo, il che credo sia una cattiva idea. Cambierò le loro definizioni e ogni nuova release richiederà lo stesso sforzo, che è attualmente ogni 3-6 mesi.

Le mie domande sono:

Sei d'accordo con argomenti fatti da me o dal fornitore? Se è così, perché?
Sono corretto nel mio suggerimento Java tratta queste configurazioni allo stesso modo?
Se ho torto, c'è un modo in cui posso dire a .Net di creare tipi nullable per minOccurs="0" ?

java .net wcf soap w3c

posta Andy Clark 07.02.2016 - 00:06

fonte

1 risposta

Leggi altre domande sui tag java .net wcf soap w3c

Due classi che dovrebbero essere uguali ma che differiscono nelle liste Utilizzo di JWT su Oauth2.0

score 0 · Answer 1

Apache CXF utilizza la seguente logica:

MinOccurs and Nillable

The default Aegis mapping is to assume that, since any Java object can be null, that the corresponding schema elements should have minOccurs of 0 and nillable of true. There are properties on the mappings to control this.

<mappings>
  <mapping>
    <property name='everpresentProperty' minOccurs='1' nillable='false'/>
 </mapping>
<mappings>

La logica del W3C è simile:

An [XML Schema 1.0], or other [XML 1.0] document containing an [XML Schema 1.0] element , exhibits the NillableElement pattern identified using the URI [RFC 3986] http://www.w3.org/2002/ws/databinding/patterns/6/09/NillableElement when the following [XPath 2.0] expression applied to a document or element node with a context node of //xs:schema results in an [XPath 2.0] node-set containing at least one node:

.//xs:element[@nillable = 'true' and not(@minOccurs = '0')]/ (@nillable)

Il seguente esempio [XML Schema 1.0] extract illustra l'uso del pattern NillableElement all'interno di un documento [XML Schema 1.0] [NillableElement]:

<xs:element name="nillableMiddleName" type="ex:NillableMiddleName" />
<xs:complexType name="NillableMiddleName">
  <xs:sequence>
    <xs:element name="firstName" type="xs:string" />
    <xs:element name="middleName" type="xs:string"  nillable="true" />
    <xs:element name="lastName" type="xs:string" />
  </xs:sequence>
</xs:complexType>

Il seguente esempio [XML 1.0] elemento è valido rispetto all'esempio precedente [XML Schema 1.0] se incluso in un documento di istanza [NillableElement01]:

<ex:nillableMiddleName>
  <ex:firstName>Paul</ex:firstName>
  <ex:middleName xsi:nil="true"/>
  <ex:lastName>Downey</ex:lastName>
</ex:nillableMiddleName>

come è il seguente elemento quando è incluso in un documento di istanza [NillableElement02]:

<ex:nillableMiddleName>
  <ex:firstName>Paul</ex:firstName>
  <ex:middleName>Sumner</ex:middleName>
  <ex:lastName>Downey</ex:lastName>
</ex:nillableMiddleName>

Riferimenti