Résolution des problèmes d’analyse GDL

Les informations suivantes couvrent certaines des causes des comportements inattendus que vous pouvez rencontrer lors de l’analyse de fichiers GDL.

Symptôme : vous incluez le fichier de schéma, mais l’analyseur émet un message d’erreur indiquant « aucun modèle 'ROOT' trouvé, les entrées GDL ne seront pas modélisées » et ignore le schéma.
Solution : vérifiez si un modèle ROOT est défini. Si un tel modèle est défini, assurez-vous que la directive #Include: schema.gdl précède les données instance. Sinon, l’analyseur ignore le schéma.

Symptôme : vous définissez un attribut plusieurs fois dans le fichier GDL, et je ne le vois apparaître dans le instantané XML qu’une seule fois.
Solution : vous devez définir un modèle pour tout attribut qui apparaît dans le instantané XML plusieurs fois. Vous devez définir la directive *Additive. Sinon, seule la définition la plus récente s’affiche.

Symptôme : l’analyseur se plaint que « [La production définie dans le modèle : « {nom du modèle} » n’est pas satisfaite par la construction réelle.] et il semble que le nombre d’occurrences de chaque membre se trouve dans les limites définies par la production.
Solution : tout d’abord, case activée quel modèle est lié à chaque entrée GDL à l’aide de l’option -i de l’analyseur GDL. La liaison ne s’est peut-être pas produite comme prévu. Si la liaison semble avoir fonctionné, n’oubliez pas que la production est satisfaite par une instance du modèle nommé dans la production et par tout instance de tout modèle dérivé du modèle nommé. Par conséquent, si la production spécifie qu’une seule instance d’un modèle particulier peut être présente et si le fichier de données réel contient deux instances d’un modèle dérivé de ce modèle, la production sera violée. L’héritage du modèle est suivi même si le modèle dérivé redéfinit la directive *Name.

Symptôme : vous recevez un message d’avertissement qui fait référence à une *InvalidCombination qui n’existe pas dans le fichier GDL en cours d’analyse.
Solution : l’analyseur GDL convertit *Constraint directives en *InvalidCombination directives en interne. Par conséquent, lorsque des erreurs sont détectées après la conversion, le message fait référence à la *Contrainte en tant que *InvalidCombination. En outre, l’ordre dans lequel chaque élément d’une *InvalidCombination est stocké en interne n’est pas nécessairement l’ordre spécifié dans le fichier GDL.

Symptôme : Un espace de fin s’affiche lorsqu’une référence de macro de valeur est remplacée par sa valeur définie.
Solution : la définition de macro de valeur contient un commentaire de fin. Déplacez le commentaire vers une ligne distincte. Dans la plupart des contextes, l’analyseur n’est pas sensible à la présence de caractères d’espace supplémentaires.

Symptôme : Entourer la syntaxe non conforme d’une construction *IgnoreBlock ne masque pas le contenu de l’analyseur, car des erreurs de syntaxe sont toujours générées.
Solution : Le contenu de *IgnoreBlock doit toujours être conforme à GDL. *IgnoreBlock empêche simplement son contenu d’apparaître dans les arborescences de données internes et empêche l’exécution de directives non préprocesseurs. Pour vraiment masquer quelque chose, utilisez des conditions de préprocesseur. Si le fragment qui est masqué lui-même contient des directives de préprocesseur qui ne doivent pas être exécutées, modifiez le préfixe du préprocesseur juste avant de placer le fragment avec des conditions de préprocesseur.

Symptôme : les fonctionnalités, les constructions et les attributs définis dans les fichiers désignés avec *PreCompiled n’apparaissent pas dans le instantané XML et ne peuvent pas être référencés par le fichier hôte.
Solution : ce symptôme se produit par conception. Vous pouvez stocker uniquement des modèles et des définitions de macros dans des fichiers précompilés.

Symptôme : vous ne pouvez pas référencer des modèles, des définitions de préprocesseur, des macros ou tout autre contenu défini ailleurs à partir de fichiers désignés avec *PréCompiled.
Solution : ce symptôme se produit par conception. Les fichiers précompilés sont conçus pour être autonomes et totalement indépendants du contexte du fichier hôte. Pour accéder à des modèles ou à d’autres contenus définis dans un autre fichier, vous devez placer une directive #Include qui nomme ce fichier directement dans le fichier #PreCompiled. Le contenu qui est indirectement inclus en raison de son inclusion (à l’aide de #Include) dans le fichier #Include (c’est-à-dire des instructions #Include imbriquées) est accessible par le fichier précompilé racine (#PreCompiled). Les fichiers précompilés peuvent inclure (à l’aide de #Include) d’autres fichiers précompilés.

Symptôme : les fonctionnalités ou les options n’apparaissent pas dans le instantané dans l’ordre dans lequel vous les avez définies. Ou bien, la première option n’est pas affectée en tant qu’option par défaut.
Solution : certaines options ont peut-être été définies précédemment dans une autre partie du fichier GDL ou dans un fichier inclus qui a été traité avant la fonctionnalité ou la définition d’option que vous examinez. La première option traitée devient la première option, la deuxième option traitée devient la deuxième option dans le instantané, et ainsi de suite.

Symptôme : vous recevez un message d’avertissement indiquant que l’analyseur GDL ne trouve pas un modèle référencé par la directive *ElementType, mais que ce modèle est défini.
Solution : seuls les modèles déclarés comme *Type : DATATYPE peuvent être référencés par la directive *ElementType.

Symptôme : les valeurs des attributs définis comme *FilterTypeName : « CODEPAGE_STRING » ne sont pas correctement converties en Unicode.
Solution : si la directive *CodePage n’est pas définie au moment de l’analyse de cet attribut, l’analyseur suppose que la chaîne est déjà en Unicode. Vérifiez que la définition *CodePage s’affiche avant les attributs CODEPAGE_STRING.

Symptôme : vous avez défini le *RequiredDelimiter dans votre tableau ou modèle de type de données composite comme une séquence de plusieurs espaces ou onglets, et l’analyseur ne semble pas reconnaître les données réelles même si elles sont conformes exactement à la définition du modèle.
Solution : l’analyseur convertit en interne toute chaîne arbitraire d’espaces blancs (espaces ou caractères de tabulation) en un seul espace. Par conséquent, lorsque la valeur est cochée, elle ne satisfait pas la définition du modèle. Pour éviter cette situation, spécifiez un seul espace pour le *RequiredDelimiter, ou utilisez un caractère non-espace blanc pour *RequiredDelimiter et utilisez l’espace et les caractères de tabulation pour *OptionalDelimiter.

Symptôme : interface DOM : la requête Xpath ne trouve aucun élément dans le instantané (par exemple, sélectionnezSingleNode(« /SnapshotRoot/GDL_ATTRIBUTE ») ne retourne rien).
Solution : Xpath suppose que les noms d’éléments sans préfixe d’espace de noms font référence à l’espace de noms null ou vide, et non à l’espace de noms par défaut. Le instantané définit un espace de noms par défaut et la plupart des éléments appartiennent à l’espace de noms par défaut.

Pour accéder à ces éléments à l’aide de Xpath, le client doit d’abord mapper cet espace de noms par défaut à un préfixe explict. Pour mapper l’espace de noms par défaut de cette façon, utilisez la méthode setProperty pbjects de document. La propriété qui doit être définie est SelectionNamespaces. Utilisez cette propriété pour affecter à l’espace de noms par défaut un préfixe explict. Dans le instantané, l’espace de noms par défaut est l’URI suivant :

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

L’appel à setProperty peut ressembler à l’exemple de code suivant :

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

Le deuxième argument de l’exemple précédent est en fait un variant, mais cette complexité supplémentaire est omise par souci de simplicité. La requête Xpath doit maintenant référencer explicitement le préfixe d’espace de noms gdl lors du référencement d’éléments dans l’espace de noms par défaut. La requête devient ensuite l’exemple de code suivant.

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

Symptôme : la propriété de l’interface DOM : nodeTypedValue retourne toujours des valeurs en tant que types BSTR, quels que soient leur xsi:type.
Solution : L’implémentation actuelle de MSXML 4.0 reconnaît uniquement les types de données lorsqu’ils sont définis à l’aide d’une définition de type de données (DTD). L’analyseur GDL utilise XSD, qui est la recommandation W3C actuelle.

Symptôme : les chaînes entre guillemets qui contiennent des caractères dont les valeurs ANSI sont comprises entre 0 et 0x19 provoquent des erreurs d’analyse XML (à l’exception des 0x0a, 0x0d et 0x09).
Solution : cette erreur est une fonctionnalité XML. Ces chaînes doivent être représentées à l’aide des formats de données binaires ou binhex xml. Les versions ultérieures de XML peuvent accepter des chaînes qui contiennent ces caractères.

Symptôme : certaines données ou schémas XML instance définis à l’aide du type PASSTHROUGH ou XSD_DEFINED provoquent des messages d’erreur d’analyseur XML ou de validation lorsqu’ils sont chargés dans dom.
Solution : La création de votre propre code XML à l’aide du PASSTHROUGH ou des types de données XSD_DEFINED contourne le code de génération XML des analyseurs GDL et vous expose aux subtilités du XML et aux bizarreries de l’analyseur DOM. Vous devez être suffisamment compétent avec XML pour gérer ces problèmes avant d’utiliser ces types de données.

Symptôme : l’analyseur indique « La préface ne peut pas être utilisée avec un fichier précompilé », mais le fichier racine ne contient pas de directive #Precompiled.
Solution : la directive #Precompiled peut résider dans la préface elle-même. L’analyseur ne peut pas distinguer si le contenu GDL provient de la préface ou du fichier racine.