noms d'éléments XML

Question

Je dois redéfinir un document XML et schéma pour mon entreprise. Le document en question est divisé en un certain nombre de sections qui contiennent chacune des informations sur un médicament, par exemple;

<dosage>overview of dose info
   <elderly>doses for elderly patients</elderly>
   <children>doses for children</children>
</dosage>
<administration>info about administering the med...</administration>

Je crois fermement que les noms d'éléments doivent être modifiés pour refléter ce que l'élément est par exemple <section> avec un attribut décrivant le contenu: <section displayName='dosage'>. Tous mes collègues sont d'accord.

Ma pensée correcte et toute personne peut fournir des principes directeurs pour la nomenclature des éléments qu'ils ont trouvé utile dans la pratique?

Answer 1

Prenons le cas de elderly et children. La balise doit définir ce que - dans ce cas, ils sont à la fois les instructions de dosage spécifiques à un certain type de personne. Mais en utilisant children et elderly ne communique pas cette information - il n'y a pas de relation là-bas. Si, au contraire, il était <instructions target="elderly">...</instructions>, cette relation est maintenue. Les deux sont instructions pour différents targets.

Pour les sections de dosage et administration, deux personnes pourraient être considérées comme des propriétés du médicament. Ce que vous faites ici dépend de la structure du document entier et comment il sera analysé. Il me semble que dosage est très distincte de administration. Si vous définissez cela comme un objet dans un OOL, vous auriez:

class Medication
{
    Dictionary<string, string> dosageInstructions; //or <PersonType, string>, preferably
    string administrationInfo;
}

Les deux sont des propriétés différentes, et il n'y a pas de véritable parallèle entre eux (bien, autre que celle qu'ils sont tous les deux propriétés du médicament). Je ne pense pas qu'il serait utile de faire abstraction que plus qu'elle ne l'est déjà, mais il est quelque chose qui pourrait faire valoir de toute façon en fonction de la structure du document entier et comment il va être utilisé.

Par exemple, si vous allez imprimer une liste de paires clé-valeur (par exemple, une clé est administration et que la valeur est l'info) pour un groupe de propriétés différentes, alors qui est le chemin à parcourir. Mais dosage a une structure distincte de administration, donc je ne pense pas que cette abstraction particulière serait utile. Si chaque médicament a un ensemble fixe de propriétés possibles (dosage, informations d'administration, etc.) qui seront tous traités différemment, alors, à mon avis, il serait logique d'utiliser des balises distinctes pour chacun d'eux.

En ce qui concerne les principes directeurs généraux, je pense en général « comment pourrais-je définir ce document comme un objet », puis considérer ce que la sérialisation XML de cet objet serait. Cela fonctionne pour moi parce que je suis beaucoup plus habitué à travailler avec des objets, mais votre kilométrage peut varier. Et il y a certainement des cas où ce n'est pas la meilleure approche - par exemple, si vous êtes vraiment un représentant Document , comme HTML, ce ne est pas la voie à suivre. Mais si vous utilisez XML pour définir une structure de données régulière, il doit généralement travailler.

Answer 2

Je l'ai trouvé que généralement il est un peu plus clair pour avoir le XML défini comme dans l'exemple que vous avez fourni.

<dosage>
   <elderly>doses for elderly patients</elderly>
   <children>doses for children</children>
</dosage>
<administration>info about administering the med...</administration>

À titre d'exemple extrême de votre nomenclature proposée vous pourriez finir avec ceci:

<field name="dosage">
    <field name="elderly">doses for elderly patients</field>
    <field name="children">doses for children</field>
</field>

Bien sûr, à la fin tout dépend de l'application spécifique, mais généralement je voudrais essayer d'abstraire enities et les propriétés du monde réel au format XML autant qu'il est nécessaire, mais pas plus.

Dans cet exemple, élément "section" est un prélèvements excessifs.

Answer 3

Je pense que ça va un peu loin. Je suis une règle de, est-il logique sémantique hors contexte? Section pourrait donner un sens hors contexte, mais vous savez que vous perdez des informations sémantiques qui sont pertinentes. Alors qu'est-ce que nous devons savoir à ce sujet? Qu'il contient des informations doosage. Alors peut-être dosageinfo serait mieux?

Suivant la même approche pour les personnes âgées et les enfants que nous assumerait ces éléments représentent les personnes âgées et les enfants. Euh ... pas vraiment. Si leurs noms reflètent ce qu'ils font, ils seraient quelque chose comme:

<dosageinfo>
<dosage recipient="elderly">Blah</dosage>
<dosage recipient="children"></dosage>
</dosageinfo>

Cela dit, ce n'est certainement pas une méthode formelle -. Je n'ai jamais vu une méthode formelle proposée

Alors que je suis ici, et ayant une expérience significative avec le traitement des données cliniques de diverses façons, je vous suggère aussi vous essayer d'obtenir une partie de votre texte libre en données XML formalisées, même si vous devez utiliser un langage naturel pour Parsing glaner certaines d'entre elles. Toutes les données formalisées, même des données glanées AI tant que son bien représenté en tant que tel, peut faire demande des informations de beaucoup plus facile à l'avenir. Il pourrait ne pas être pertinent à votre scénario, mais je pense qu'il est utile d'examiner.

Les données en texte libre est utile que des informations. Les données dans les relations est des données et des informations.