2009-04-27 5 views
1

Nous utilisons XML pour définir un schéma de contrôle des contenus pouvant être affichés dans un outil de création de diagrammes. Le fichier de schéma spécifie quels types d'objets peuvent être placés sur le diagramme, comment ils peuvent être liés entre eux et quelles propriétés ont ces objets (c'est-à-dire, quelles propriétés paramétrables apparaissent dans l'éditeur).xml: est l'utilisation de plusieurs niveaux! ENTITY possible?

Lorsqu'un nouveau type de diagramme est nécessaire, un nouveau schéma est écrit et validé par rapport à un fichier .xsd. Afin de rendre le fichier de schéma plus modulaire et plus facile à maintenir, nous utilisons des déclarations pour inclure des fichiers séparés. Les listes de propriétés, etc., qui appartiennent ensemble sur un élément de diagramme particulier, mais qui pourraient apparaître à plusieurs endroits dans le schéma, sont écrites dans un fichier xml séparé, et ensuite incluses à l'endroit approprié. Dis:

<!-- Nameing etc. just as an example --> 
<!ENTITY CommonProerties1 SYSTEM "file:../CommonProperties1.xml"> 
<!ENTITY CommonProerties2 SYSTEM "file:../CommonProperties2.xml"> 

puis quelque part dans le schéma:

<Node shape="Square"> 
    &CommonProperties1; 
    <!-- Specific properties go here --> 
</Node> 

Cela empêche beaucoup de copier des trucs cipé qui rend la maintenance difficile, et permet des propriétés commmpn être partagées avec plusieurs schémas aussi. Le problème est que maintenant, certaines des propriétés communes ont aussi des éléments de base, tels que des groupes de drapeaux et d'énumérations, etc. Je voudrais que chaque fichier (tel que "CommonProperties1.xml") puisse inclure un autre ensemble de base tel que "CommonEnums.xml", mais je ne pense pas que ce soit possible en utilisant! ENTITY declaractions.

Vous ne pouvez pas déclarer un! ENTITY en-dehors d'un en-tête DOCTYPE, et si vous ajoutez l'en-tête, le fichier xml de niveau supérieur est invalide car il obtient une déclaration d'en-tête à travers le fichier.

Est-ce que quelqu'un a déjà essayé de faire des choses similaires, et qu'avez-vous fait pour contourner/résoudre le problème? Y a-t-il une meilleure option qui me manque?

Vive toute aide,

Xan

Répondre

3

entités générales du système ont été conçus pour être utilisés comme un texte include/mécanisme de remplacement. J'ai vu des structures profondément imbriquées avec une plaque de grande complexité.

Alors, creusons un peu plus profondément dans votre énoncé de problème.

Dans votre exemple, pourquoi pensez-vous que vous ne pouvez pas avoir une déclaration! ENTITY pour CommonEnums dans la déclaration de type de document de sorte que la référence d'entité & CommonEnums soit reconnue lorsque l'entité conteneur est analysée? Quelle est la particularité de ces entités système que vous rencontrez des difficultés à déclarer? Si votre objectif est d'éviter d'avoir à les déclarer lors de l'analyse du prologue du document, alors, non, vous ne pouvez pas contourner cela.

Vous ne pouvez pas déclarer! ENTITÉ en dehors d'un en-tête! DOCTYPE

Cela est vrai dans un sens, mais il y a une échappatoire utile. Vous pouvez déclarer des entités générales dans une DTD externe, auquel cas leur déclaration n'est pas physiquement visible dans le prologue du document. Je ne sais pas si cela est utile dans votre situation, mais déclarer vos entités de système général externes dans une DTD vous permettrait de les "cacher" des instances de document et des fragments qui s'y réfèrent.

Si je pense que vos objectifs sont la réutilisabilité, la modularité et la finesse, alors je pense que vous pouvez faire ce que vous voulez au moyen d'une DTD externe. Mais pour tirer parti de cette fonctionnalité, vous devrez peut-être effectuer tout le travail de création d'une DTD, plus ou moins, dans la mesure nécessaire pour satisfaire votre processeur XML, qui insistera probablement pour valider vos structures de document par rapport à la DTD.

+0

Pas possible de faire ce que nous espérions, merci pour vos conseils. – xan

Questions connexes