Per visualizzare l'articolo in inglese, selezionare la casella di controllo Inglese. È possibile anche visualizzare il testo inglese in una finestra popup posizionando il puntatore del mouse sopra il testo.
Traduzione
Inglese

NIB: problemi noti in System.Xml

In questa sezione vengono descritti i problemi noti relativi all'implementazione System.Xml.

Esistono alcune differenze tra il foglio di stile XSLT compilato in modalità debug e il foglio di stile XSLT compilato in modalità di rilascio. In alcune situazioni i fogli di stile compilati in modalità debug non generano errori durante l'operazione Load, ma riporteranno errori successivamente durante l'operazione Transform. Lo stesso foglio di stile compilato in modalità di rilascio avrà esito negativo durante l'operazione Load.

Un esempio di tale comportamento si ottiene quando una variabile che non è del tipo set di nodi viene assegnata a un'espressione in cui è richiesto un set di nodi.

L'implementazione System.Xml delle raccomandazioni W3C (World Wide Web Consortium) per XML Schema utilizza la classe RegEx per eseguire i criteri di ricerca delle espressioni regolari. In alcuni casi, il comportamento consigliato da W3C è diverso dal comportamento della classe RegEx. Di seguito sono riportati i casi noti in cui l'implementazione System.Xml dei criteri di ricerca è diversa dalla specifica W3C:

  • In base alla specifica W3C per XML Schema, il segno di dollaro ($) deve essere considerato un carattere normale. Tuttavia, la convalida di System.Xml interpreta il segno di dollaro in xs:pattern come ancoraggio di fine riga. Una possibile soluzione alternativa consiste nel sostituire $ con [$]. Se il criterio è già racchiuso tra parentesi, come ad esempio [abc$], non è necessario apportare alcuna modifica.

  • La classe RegEx segue la definizione di \p{C} dello standard Unicode. Lo standard Unicode definisce la categoria generale C come Cc | Cf | Cn | Co | Cs, dove la categoria Cs identifica i caratteri surrogati. Poiché i caratteri surrogati non sono presenti a livello di astrazione di carattere utilizzato dai documenti di istanza XML, W3C modifica la definizione di \p{C} rimuovendo la proprietà Cs dal gruppo. Per evitare errori di convalida XML, impostare \p{C} in xs:pattern sulla stringa letterale \p{Cc}|\p{Cf}|\p{Co}|\p{Cn}.

Le raccomandazioni W3C per XML Schema specificano che il tipo di dati xs:time deve considerare valido il valore 24:00:00 e che 24:00:00 indica la prima istanza del giorno successivo.

L'implementazione System.Xml non considera valido il valore 24:00:00. Se si assegna il valore 24:00:00 a un elemento di tipo xs:time, si verificherà un errore di convalida.

In alcuni casi, quando vengono utilizzati i gruppi di sostituzione, l'implementazione System.Xml non soddisfa il vincolo Schema Component Constraint: Element Declarations Consistent (Vincolo componenti di schema: Dichiarazioni di elementi coerenti) descritto nella sezione Constraints on Model Group Schema Components della specifica W3C.

Nello schema seguente, ad esempio, sono riportati elementi con lo stesso nome ma tipi diversi nello stesso modello di contenuto e vengono utilizzati i gruppi di sostituzione. Sebbene tale schema debba generare un errore, System.Xml lo compila e lo convalida senza errori.

<?xml version="1.0" encoding="utf-8" ?> 
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">

   <xs:element name="e1" type="t1"/>
   <xs:complexType name="t1"/>

   <xs:element name="e2" type="t2" substitutionGroup="e1"/>
      <xs:complexType name="t2">
         <xs:complexContent>
            <xs:extension base="t1">
         </xs:extension>
      </xs:complexContent>
   </xs:complexType>

   <xs:complexType name="t3">
      <xs:sequence>
         <xs:element ref="e1"/>
         <xs:element name="e2" type="xs:int"/>
      </xs:sequence>
   </xs:complexType>
</xs:schema>

In questo schema il tipo t3 contiene una sequenza di elementi.A causa della sostituzione, il riferimento all'elemento e1 della sequenza può restituire un elemento e1 di tipo t1 o un elemento e2 di tipo t2.Nel secondo caso viene generata una sequenza di due elementi e2, dove il primo elemento e2 è di tipo t2, mentre il secondo elemento e2 è di tipo xs:int.

L'implementazione System.Xml non soddisfa il vincolo Schema Component Constraint: Unique Particle Attribution della specifica W3C in presenza delle condizioni seguenti:

  • Uno degli elementi nel gruppo fa riferimento a un altro elemento.

  • L'elemento a cui si fa riferimento è un elemento Head di un gruppo di sostituzione.

  • Nel gruppo di sostituzione è presente un elemento con lo stesso nome di uno degli elementi del gruppo.

  • La cardinalità dell'elemento che fa riferimento all'elemento Head del gruppo di sostituzione e all'elemento con lo stesso nome di uno degli elementi del gruppo di sostituzione non è fissa (minOccurs < maxOccurs).

  • La definizione dell'elemento che fa riferimento al gruppo di sostituzione precede la definizione dell'elemento con lo stesso nome di uno degli elementi del gruppo di sostituzione.

Sebbene, ad esempio, nello schema seguente il modello di contenuto sia ambiguo e debba generare un errore di compilazione, System.Xml lo compila senza errori.

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">

  <xs:element name="e1" type="xs:int"/>
  <xs:element name="e2" type="xs:int" substitutionGroup="e1"/>

  <xs:complexType name="t3">
    <xs:sequence>
      <xs:element ref="e1" minOccurs="0" maxOccurs="1"/>
      <xs:element name="e2" type="xs:int" minOccurs="0" maxOccurs="1"/>
    </xs:sequence>
  </xs:complexType>
  
  <xs:element name="e3" type="t3"/>
</xs:schema>

Se si tenta di convalidare l'XML seguente rispetto allo schema sopra riportato, la convalida non riuscirà e verrà visualizzato il messaggio "L'elemento 'e3' ha un elemento figlio non valido 'e2'". XmlSchemaValidationException.

<e3>

<e2>1</e2>

<e2>2</e2>

</e3>

Una possibile soluzione alternativa consiste nell'invertire le dichiarazioni dell'elemento nel documento XSD.Ad esempio:

    <xs:sequence>
      <xs:element ref="e1" minOccurs="0" maxOccurs="1"/>
      <xs:element name="e2" type="xs:int" minOccurs="0" maxOccurs="1"/>
    </xs:sequence>

diventa:

    <xs:sequence>
      <xs:element name="e2" type="xs:int" minOccurs="0" maxOccurs="1"/>
      <xs:element ref="e1" minOccurs="0" maxOccurs="1"/>
    </xs:sequence>

Un altro esempio dello stesso problema viene illustrato nello schema seguente.

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
   <xs:element name="e1" type="xs:string"/>
   <xs:element name="e2" type="xs:string" substitutionGroup="e1"/>
   
   <xs:complexType name="t3">
      <xs:sequence>
         <xs:element ref="e1" minOccurs="0" maxOccurs="1"/>
         <xs:element name="e2" type="xs:int" minOccurs="0" maxOccurs="1"/>
      </xs:sequence>
   </xs:complexType>
   <xs:element name="e3" type="t3"/>
</xs:schema>

Se si tenta di convalidare l'XML seguente rispetto allo schema sopra riportato, la convalida non riuscirà e verrà visualizzata l'eccezione "Eccezione non gestita: System.Xml.Schema.XmlSchemaValidationException: L'elemento 'e2' non è valido. Il valore 'abc' non è valido per il tipo di dati 'http://www.w3.org/2001/XMLSchema: int'. La stringa 'abc' non è un valore Int32 valido.--"\

<e3><e2>abc</e2></e3>
Mostra: