Risoluzione dei problemi relativi all'analisi GDL

Le informazioni seguenti illustrano alcune delle cause di comportamenti imprevisti che potrebbero verificarsi durante l'analisi dei file GDL.

Sintomo: si include il file dello schema, ma il parser genera un messaggio di errore che indica "nessun modello RADICE" trovato, le voci GDL non verranno templatizzate" e ignora lo schema.
Soluzione: verificare se è definito un modello ROOT. Se tale modello è definito, assicurarsi che la direttiva #Include: schema.gdl venga eseguita prima di tutti i dati dell'istanza. In caso contrario, il parser ignorerà lo schema.

Sintomo: si definisce un attributo più volte nel file GDL e viene visualizzato nello snapshot XML una sola volta.
Soluzione: è necessario definire un modello per qualsiasi attributo visualizzato nello snapshot XML più volte. È necessario definire la direttiva *Additive. In caso contrario, verrà visualizzata solo la definizione più recente.

Sintomo: il parser si lamenta che "[Produzione definita nel modello: "{nome modello}" non è soddisfatta dal costrutto effettivo.]", e sembra che il numero di occorrenze di ogni membro si trova entro i limiti definiti dall'ambiente di produzione.
Soluzione: controllare prima di tutto il modello associato a ogni voce GDL usando l'opzione -i del parser GDL. L'associazione potrebbe non essere stata eseguita come previsto. Se l'associazione sembra aver funzionato, tenere presente che l'ambiente di produzione è soddisfatto da un'istanza del modello denominata nell'ambiente di produzione e da qualsiasi istanza di qualsiasi modello derivato dal modello denominato. Quindi, se l'ambiente di produzione specifica che può essere presente una sola istanza di un modello specifico e se il file di dati effettivo contiene due istanze di un modello derivato da tale modello, l'ambiente di produzione verrà violato. L'ereditarietà del modello viene rilevata anche se il modello derivato ridefine la direttiva *Name.

Sintomo: viene visualizzato un messaggio di avviso che fa riferimento a un oggetto *InvalidCombination che non esiste nel file GDL analizzato.
Soluzione: il parser GDL converte *Direttive vincolo in direttive *InvalidCombination internamente. Quindi, quando vengono rilevati errori dopo la conversione, il messaggio fa riferimento al *Vincolo come *InvalidCombination. Inoltre, l'ordine in cui ogni elemento di un oggetto *InvalidCombination viene archiviato internamente non è necessariamente l'ordine specificato nel file GDL.

Sintomo: lo spazio finale spurio viene visualizzato quando un riferimento alla macro del valore viene sostituito con il relativo valore definito.
Soluzione: la definizione della macro valore contiene un commento finale. Spostare il commento in una riga separata. Nella maggior parte dei contesti, il parser è insensibile alla presenza di caratteri di spazio aggiuntivi.

Sintomo: la sintassi circostante non conforme con un costrutto *IgnoreBlock non nasconde il contenuto dal Parser come errori di sintassi vengono comunque generati.
Soluzione: il contenuto di *IgnoreBlock deve comunque essere conforme a GDL. *IgnoreBlock impedisce solo la visualizzazione del contenuto negli alberi dati interni e impedisce l'esecuzione di direttive non preprocessore. Per nascondere veramente qualcosa, usare i condizionali del preprocessore. Se il frammento nascosto contiene direttive del preprocessore che non devono essere eseguite, modificare il prefisso del preprocessore appena prima di racchiudere il frammento con condizionali del preprocessore.

Sintomo: le funzionalità, i costrutti e gli attributi definiti all'interno di file designati con *PreCompiled non vengono visualizzati nello snapshot XML e non possono essere a cui fa riferimento il file host.
Soluzione: questo sintomo si verifica in base alla progettazione. È possibile archiviare solo modelli e definizioni di macro all'interno di file precompilati.

Sintomo: non è possibile fare riferimento a modelli, preprocessore definisce, macro o altri contenuti definiti altrove dall'interno di file designati con *PreCompiled.
Soluzione: questo sintomo si verifica in base alla progettazione. I file precompilati sono progettati per essere indipendenti e completamente indipendenti dal contesto del file host. Per accedere ai modelli o ad altri contenuti definiti in un altro file, è necessario inserire una direttiva #Include che nomi il file direttamente all'interno del file #PreCompiled. Il contenuto incluso indirettamente grazie all'inserimento (usando #Include) all'interno del file #Include (ovvero, istruzioni di #Include annidate) sarà accessibile dal file precompilato (#PreCompiled) radice. I file precompilati possono includere (usando #Include) altri file precompilati.

Sintomo: le funzionalità o le opzioni non vengono visualizzate nello snapshot nell'ordine definito. In alternativa, la prima opzione non viene assegnata come opzione predefinita.
Soluzione: alcune opzioni potrebbero essere state definite in precedenza in un'altra parte del file GDL o in un file incluso elaborato prima della definizione di funzionalità o opzione che si sta esaminando. La prima opzione elaborata diventa la prima opzione, la seconda opzione elaborata diventa la seconda opzione nello snapshot e così via.

Sintomo: viene visualizzato un messaggio di avviso che indica che il parser GDL non riesce a trovare un modello a cui fa riferimento la direttiva *ElementType, ma tale modello è definito.
Soluzione: solo i modelli dichiarati come *Type: DATATYPE possono essere a cui fa riferimento la direttiva *ElementType.

Sintomo: i valori degli attributi definiti come *FilterTypeName: "CODEPAGE_STRING" non vengono convertiti correttamente in Unicode.
Soluzione: se la direttiva *CodePage non è definita al momento dell'analisi di questo attributo, il parser presuppone che la stringa sia già in Unicode. Assicurarsi che la definizione *CodePage venga visualizzata prima di qualsiasi attributo CODEPAGE_STRING.

Sintomo: è stato definito il modello *RequiredDelimiter nella matrice o nel modello di tipo di dati composito per essere una sequenza di più caratteri o schede di spazio e il parser non sembra riconoscere i dati effettivi anche se è conforme esattamente alla definizione del modello.
Soluzione: il parser converte internamente qualsiasi stringa arbitraria di spazi vuoti (spazio o caratteri di tabulazioni) in un singolo carattere di spazio. Quindi, quando viene controllato il valore, non soddisfa la definizione del modello. Per evitare questa situazione, specificare solo uno spazio per *RequiredDelimiter o usare un carattere di spazio non vuoto per *RequiredDelimiter e usare lo spazio e i caratteri tabulazioni per *OptionalDelimiter.

Sintomo: interfaccia DOM: Query Xpath non riesce a trovare elementi nello snapshot (ad esempio, selezionareSingleNode("/SnapshotRoot/GDL_ATTRIBUTE") non restituisce nulla.
Soluzione: Xpath presuppone che i nomi degli elementi senza un prefisso dello spazio dei nomi facciano riferimento allo spazio dei nomi Null o vuoto, non allo spazio dei nomi predefinito. Lo snapshot definisce uno spazio dei nomi predefinito e la maggior parte degli elementi appartiene allo spazio dei nomi predefinito.

Per accedere a questi elementi usando Xpath, il client deve prima eseguire il mapping di questo spazio dei nomi predefinito a un prefisso explict. Per eseguire il mapping dello spazio dei nomi predefinito in questo modo, usare il metodo setProperty del documento pbjects. La proprietà che deve essere impostata è SelectionNamespaces. Usare questa proprietà per assegnare lo spazio dei nomi predefinito un prefisso explict. Nello snapshot lo spazio dei nomi predefinito è questo URI:

https://schemas.microsoft.com/2002/print/gdl/1.0

La chiamata a setProperty potrebbe essere simile all'esempio di codice seguente:

XMLDoc->setProperty(L"SelectionNamespaces", "xmlns:gdl=\"https://schemas.microsoft.com/2002/print/gdl/1.0\"");

Il secondo argomento nell'esempio precedente è in realtà un valore Variant, ma questa complessità aggiunta viene omessa per semplicità. La query Xpath deve ora fare riferimento in modo esplicito al prefisso dello spazio dei nomi gdl quando si fa riferimento agli elementi nello spazio dei nomi predefinito. La query diventa quindi l'esempio di codice seguente.

selectSingleNode("/gdl:SnapshotRoot/gdl:GDL_ATTRIBUTE")

Sintomo: l'interfaccia DOM: la proprietà nodeTypedValue restituisce sempre valori come tipi BSTR, indipendentemente dal tipo xsi:type.
Soluzione: l'implementazione corrente di MSXML 4.0 riconosce solo i tipi di dati quando vengono definiti usando una definizione del tipo di dati (DTD). Il parser GDL usa XSD, ovvero la raccomandazione W3C corrente.

Sintomo: le stringhe con virgolette che contengono caratteri con valori ANSI compresi tra 0 e 0x19 causano errori di analisi XML (ad eccezione di 0x0a, 0x0d e 0x09).
Soluzione: questo errore è una funzionalità XML. Tali stringhe devono essere rappresentate usando i formati di dati binari o binhex di XML. Le versioni future di XML potrebbero accettare stringhe contenenti questi caratteri.

Sintomo: alcuni dati dell'istanza XML o dello schema definiti usando pass THROUGH o XSD_DEFINED tipi di dati causano messaggi di errore di analisi XML o di convalida quando vengono caricati in DOM.
Soluzione: la creazione di un codice XML personalizzato tramite pass THROUGH o XSD_DEFINED tipi di dati ignora il codice di generazione XML dei parser GDL ed espone agli intrichi di XML e quirk nel parser DOM. È consigliabile essere abbastanza esperti con XML per gestire tali problemi prima di usare questi tipi di dati.

Sintomo: il parser dice "Non è possibile usare prefazione con un file precompilato", ma il file radice non contiene una direttiva #Precompiled.
Soluzione: la direttiva #Precompiled potrebbe effettivamente risiedere nella prefazione stessa. Il parser non può distinguere se il contenuto GDL proviene dalla prefazione o dal file radice.