Problembehandlung bei der GDL-Analyse

In den folgenden Informationen werden einige der Ursachen für unerwartete Verhaltensweisen behandelt, die beim Analysieren von GDL-Dateien auftreten können.

Symptom: Sie schließen die Schemadatei ein, aber der Parser gibt eine Fehlermeldung mit dem Hinweis "keine 'ROOT'-Vorlage gefunden, GDL-Einträge werden nicht vorlagenisiert" aus und ignoriert das Schema.
Lösung: Überprüfen Sie, ob eine ROOT-Vorlage definiert ist. Wenn eine solche Vorlage definiert ist, stellen Sie sicher, dass die #Include: schema.gdl-Direktive vor allen instance Daten steht. Andernfalls ignoriert der Parser das Schema.

Symptom: Sie definieren ein Attribut mehrmals in der GDL-Datei, und ich sehe, dass es im XML-Momentaufnahme nur einmal angezeigt wird.
Lösung: Sie müssen eine Vorlage für jedes Attribut definieren, das mehrmals im XML-Momentaufnahme angezeigt wird. Sie müssen die *Additive-Direktive definieren. Andernfalls wird nur die neueste Definition angezeigt.

Symptom: Der Parser beschwert sich, dass "[In Vorlage: "{Vorlagenname}" definierte Produktion mit dem tatsächlichen Konstrukt nicht erfüllt ist.]", und es scheint, dass die Anzahl der Vorkommen der einzelnen Member innerhalb der Grenzen liegt, die die Produktion definiert.
Lösung: Überprüfen Sie zunächst, welche Vorlage an jeden GDL-Eintrag gebunden ist, indem Sie die Option -i des GDL-Parsers verwenden. Die Bindung ist möglicherweise nicht wie erwartet erfolgt. Wenn die Bindung funktioniert zu haben scheint, denken Sie daran, dass die Produktion durch eine instance der Vorlage, die in der Produktion benannt wurde, und durch alle instance einer beliebigen Vorlage, die von der benannten Vorlage abgeleitet wird, erfüllt wird. Wenn die Produktion also angibt, dass nur eine instance einer bestimmten Vorlage vorhanden sein kann, und wenn die tatsächliche Datendatei zwei Instanzen einer Vorlage enthält, die von dieser Vorlage abgeleitet wurden, wird die Produktion verletzt. Die Vorlagenvererbung wird auch dann nachverfolgt, wenn die abgeleitete Vorlage die *Name-Direktive neu definiert.

Symptom: Sie erhalten eine Warnmeldung, die auf eine *InvalidCombination verweist, die in der GDL-Datei, die analysiert wird, nicht vorhanden ist.
Lösung: Der GDL-Parser konvertiert *Constraint-Direktiven intern in *InvalidCombination-Anweisungen. Wenn also nach der Konvertierung Fehler erkannt werden, bezieht sich die Meldung auf die *Einschränkung als *InvalidCombination. Außerdem entspricht die Reihenfolge, in der jedes Element einer *InvalidCombination intern gespeichert wird, nicht unbedingt der Reihenfolge, die in der GDL-Datei angegeben ist.

Symptom: Falsches nachgestelltes Leerzeichen wird angezeigt, wenn ein Wertmakroverweis durch den definierten Wert ersetzt wird.
Lösung: Die Wertmakrodefinition enthält einen nachfolgenden Kommentar. Verschieben Sie den Kommentar in eine separate Zeile. In den meisten Kontexten ist der Parser nicht vom Vorhandensein zusätzlicher Leerzeichen abhängig.

Symptom: Wenn Sie eine nicht konforme Syntax mit einem *IgnoreBlock-Konstrukt umgeben, wird der Inhalt nicht aus dem Parser ausgeblendet, da weiterhin Syntaxfehler generiert werden.
Lösung: Der Inhalt von *IgnoreBlock muss weiterhin GDL-konform sein. *IgnoreBlock verhindert lediglich, dass der Inhalt in den internen Datenstrukturen angezeigt wird, und verhindert, dass alle Nicht-Präprozessordirektiven ausgeführt werden. Um etwas wirklich auszublenden, verwenden Sie Präprozessor-Bedingungen. Wenn das fragment, das selbst ausgeblendet wird, Präprozessordirektiven enthält, die nicht ausgeführt werden sollen, ändern Sie das Präfix des Präprozessors, bevor Sie das Fragment mit Präprozessor-Bedingungen einschließen.

Symptom: Features, Konstrukte und Attribute, die in Dateien definiert sind, die mit *PreCompiled festgelegt sind, werden nicht im XML-Momentaufnahme angezeigt und können nicht von der Hostdatei referenziert werden.
Lösung: Dieses Symptom tritt standardmäßig auf. Sie können nur Vorlagen und Makrodefinitionen in vorkompilierten Dateien speichern.

Symptom: Sie können nicht auf Vorlagen, Präprozessordefinitionen, Makros oder andere Inhalte verweisen, die an anderer Stelle in Dateien definiert sind, die mit *PreCompiled festgelegt sind.
Lösung: Dieses Symptom tritt standardmäßig auf. Vorkompilierte Dateien sind eigenständig und vollständig unabhängig vom Kontext der Hostdatei konzipiert. Um auf Vorlagen oder andere Inhalte zuzugreifen, die in einer anderen Datei definiert sind, müssen Sie eine #Include-Direktive platzieren, die diese Datei direkt in der #PreCompiled-Datei benennt. Inhalte, die indirekt aufgrund der Aufnahme (mithilfe von #Include) in die #Include-Datei (d. h. geschachtelte #Include-Anweisungen) eingeschlossen werden, können über die vorkompilierte Stammdatei (#PreCompiled) zugegriffen werden. Vorkompilierte Dateien können (mithilfe von #Include) andere vorkompilierte Dateien enthalten.

Symptom: Features oder Optionen werden im Momentaufnahme nicht in der Reihenfolge angezeigt, in der Sie sie definiert haben. Oder die erste Option wird nicht als Standardoption zugewiesen.
Lösung: Einige Optionen wurden möglicherweise zuvor in einem anderen Teil der GDL-Datei oder in einer enthaltenen Datei definiert, die vor der feature- oder optionsdefinition verarbeitet wurde, die Sie sich ansehen. Die erste verarbeitete Option wird zur ersten Option, die zweite verarbeitete Option wird zur zweiten Option im Momentaufnahme usw.

Symptom: Sie erhalten eine Warnmeldung, die besagt, dass der GDL-Parser keine Vorlage finden kann, auf die von der *ElementType-Direktive verwiesen wird, aber diese Vorlage definiert ist.
Lösung: Nur Vorlagen, die als *Type: DATATYPE deklariert sind, können von der *ElementType-Direktive referenziert werden.

Symptom: Werte von Attributen, die als *FilterTypeName: "CODEPAGE_STRING" definiert sind, werden nicht ordnungsgemäß in Unicode konvertiert.
Lösung: Wenn die *CodePage-Direktive zum Zeitpunkt der Analyse dieses Attributs nicht definiert ist, geht der Parser davon aus, dass die Zeichenfolge bereits in Unicode vorhanden ist. Stellen Sie sicher, dass die *CodePage-Definition vor allen CODEPAGE_STRING Attributen angezeigt wird.

Symptom: Sie haben den *RequiredDelimiter in Ihrer Array- oder Verbunddatentypvorlage als Sequenz von mehreren Leerzeichen oder Registerkarten definiert, und der Parser scheint die tatsächlichen Daten nicht zu erkennen, obwohl er genau der Vorlagendefinition entspricht.
Lösung: Der Parser konvertiert intern beliebige Leerzeichenzeichenfolgen (Leerzeichen oder Tabstoppzeichen) in ein einzelnes Leerzeichen. Wenn der Wert also überprüft wird, erfüllt er nicht die Vorlagendefinition. Um dies zu vermeiden, geben Sie nur ein Leerzeichen für *RequiredDelimiter an, oder verwenden Sie ein Leerzeichen ohne Leerzeichen für den *RequiredDelimiter, und verwenden Sie das Leerzeichen und die Tabulatorzeichen für *OptionalDelimiter.

Symptom: DOM-Schnittstelle: Xpath Query kann keine Elemente im Momentaufnahme finden (z. B. gibt selectSingleNode("/SnapshotRoot/GDL_ATTRIBUTE") nichts zurück).
Lösung: Xpath geht davon aus, dass Elementnamen ohne Namespacepräfix auf den NULL- oder leeren Namespace und nicht auf den Standardnamespace verweisen. Die Momentaufnahme definiert einen Standardnamespace, und die meisten Elemente gehören zum Standardnamespace.

Um mithilfe von Xpath auf diese Elemente zuzugreifen, muss der Client diesen Standardnamespace zunächst einem Explict-Präfix zuordnen. Um den Standardnamespace auf diese Weise zuzuordnen, verwenden Sie die setProperty-Methode für dokument pbjects. Die Eigenschaft, die festgelegt werden muss, ist SelectionNamespaces. Verwenden Sie diese Eigenschaft, um dem Standardnamespace ein Explict-Präfix zuzuweisen. Im Momentaufnahme ist der Standardnamespace der folgende URI:

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

Der Aufruf von setProperty kann wie im folgenden Codebeispiel aussehen:

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

Das zweite Argument im vorherigen Beispiel ist tatsächlich ein Variant-Argument, aber diese zusätzliche Komplexität wird der Einfachheit halber weggelassen. Die Xpath-Abfrage muss jetzt explizit auf das Namespacepräfix gdl verweisen, wenn auf Elemente im Standardnamespace verwiesen wird. Die Abfrage wird dann zum folgenden Codebeispiel.

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

Symptom: Die DOM-Schnittstelle: nodeTypedValue-Eigenschaft gibt werte immer als BSTR-Typen zurück, unabhängig von deren xsi:type.
Lösung: Die aktuelle Implementierung von MSXML 4.0 erkennt nur Datentypen, wenn sie mithilfe einer Datentypdefinition (DTD) definiert werden. Der GDL-Parser verwendet XSD, die aktuelle W3C-Empfehlung.

Symptom: Zeichenfolgen in Anführungszeichen mit ANSI-Werten zwischen 0 und 0x19 verursachen XML-Analysefehler (mit Ausnahme von 0x0a, 0x0d und 0x09).
Lösung: Dieser Fehler ist ein XML-Feature. Solche Zeichenfolgen müssen mit dem binär- oder binhex-Datenformat von XML dargestellt werden. Zukünftige Versionen von XML akzeptieren möglicherweise Zeichenfolgen, die diese Zeichen enthalten.

Symptom: Einige XML-instance Daten oder Schemas, die mithilfe von PASSTHROUGH- oder XSD_DEFINED-Datentypen definiert werden, verursachen XML-Parser- oder Validierungsfehlermeldungen, wenn sie in DOM geladen werden.
Lösung: Beim Erstellen einer eigenen XML-Datei mithilfe von PASSTHROUGH- oder XSD_DEFINED-Datentypen wird der XML-Generierungscode der GDL-Parser umgangen und Sie den Feinheiten von XML und Macken im DOM-Parser verfügbar gemacht. Sie sollten mit XML vertraut sein, um solche Probleme zu behandeln, bevor Sie diese Datentypen verwenden.

Symptom: Der Parser sagt "Preface kann nicht mit einer vorkompilierten Datei verwendet werden", aber die Stammdatei enthält keine #Precompiled-Direktive.
Lösung: Die #Precompiled-Direktive befindet sich möglicherweise im Vorwort selbst. Der Parser kann nicht unterscheiden, ob GDL-Inhalt aus dem Vorwort oder der Stammdatei stammt.