Dois-je utiliser des éléments ou des atsortingbuts en XML?

J’apprends les atsortingbuts XML de W3Schools .

L’auteur mentionne ce qui suit (emphase la mienne):

Éléments XML vs. Atsortingbuts

 Anna Smith  

  female Anna Smith  

Dans le premier exemple, le sexe est un atsortingbut. En dernier lieu, le sexe est un élément. Les deux exemples fournissent les mêmes informations.

Il n’y a pas de règles sur le moment d’utiliser des atsortingbuts et quand utiliser des éléments. Les atsortingbuts sont pratiques en HTML. En XML, je vous conseille de les éviter. Utilisez plutôt des éléments.

Éviter les atsortingbuts XML?

Certains des problèmes d’utilisation des atsortingbuts sont les suivants:

  • les atsortingbuts ne peuvent pas contenir plusieurs valeurs (les éléments peuvent)
  • les atsortingbuts ne peuvent pas contenir d’arborescence (les éléments peuvent)
  • les atsortingbuts ne sont pas facilement extensibles (pour les modifications futures)

Les atsortingbuts sont difficiles à lire et à maintenir. Utilisez des éléments pour les données. Utilisez des atsortingbuts pour des informations non pertinentes pour les données.

La vision de l’auteur est-elle célèbre ou est-ce la meilleure pratique en XML?

Les atsortingbuts en XML doivent-ils être évités?

W3Schools a également mentionné ce qui suit (souligné par moi-même):

Atsortingbuts XML pour les métadonnées

Parfois, les références d’ID sont atsortingbuées aux éléments. Ces identifiants peuvent être utilisés pour identifier des éléments XML de la même manière que l’atsortingbut ID en HTML. Cet exemple montre ceci:

   Tove Jani Reminder Don't forget me this weekend!   Jani Tove Re: Reminder I will not   

L’identifiant ci-dessus n’est qu’un identifiant permettant d’identifier les différentes notes. Ce n’est pas une partie de la note elle-même.

Ce que j’essaie de dire ici, c’est que les métadonnées (données sur les données) doivent être stockées en tant qu’atsortingbuts et que les données elles-mêmes doivent être stockées en tant qu’éléments.

    L’utilisation d’atsortingbuts ou d’éléments est généralement déterminée par les données que vous essayez de modéliser.

    Par exemple, si une entité donnée fait partie des données, il est conseillé d’en faire un élément. Par exemple, le nom de l’employé est une partie essentielle des données de l’employé.

    Maintenant, si vous voulez transmettre des données METADATA sur les données (quelque chose qui fournit des informations supplémentaires sur les données) mais qui ne font pas vraiment partie des données, il vaut mieux en faire un atsortingbut. Par exemple, disons que chaque employé a un GUID nécessaire pour le traitement du back-end, puis en faire un atsortingbut est meilleur (GUID n’est pas quelque chose qui transmet des informations vraiment utiles à quelqu’un qui regarde le XML, mais pourrait être nécessaire à d’autres fins)

    Il n’y a pas de règle en tant que telle qui dit que quelque chose devrait être un atsortingbut ou un élément.

    Il n’est pas nécessaire d’éviter les atsortingbuts à tout prix .. Parfois, ils sont plus faciles à modéliser, que les éléments. Cela dépend vraiment des données que vous essayez de représenter.

    Ce qui n’est pas moins important, c’est que mettre des éléments dans des atsortingbuts rend le XML moins verbeux.

    Comparer

      

    Contre

       John    23    m   

    Oui, c’était un peu biaisé et exagéré, mais vous avez compris

    Mon 0,02 cinq ans après l’OP est exactement le contraire. Laisse-moi expliquer.

    1. Utilisez des éléments lorsque vous regroupez des données similaires et des atsortingbuts de ces données.
    2. N’utilisez pas d’éléments pour tout.
    3. Si les données se répètent (1 à plusieurs), c’est probablement un élément
    4. Si les données ne se répètent jamais et n’ont de sens que lorsqu’elles sont liées à quelque chose d’autre, c’est un atsortingbut.
    5. Si les données n’ont pas d’autres atsortingbuts (c.-à-d. Un nom), alors c’est un atsortingbut
    6. Regrouper des éléments similaires pour prendre en charge l’parsing syntaxique des collections (c.-à-d. / Xml / caractère)
    7. Réutiliser des noms d’éléments similaires pour prendre en charge les données d’parsing
    8. Jamais, jamais , utiliser des nombres dans les noms d’éléments pour afficher la position. (ie character1, character2) Cette pratique rend très difficile l’parsing (voir # 6, le code d’parsing doit / character1, / character2, etc. pas simplement / caractère).

    Considéré autrement:

    • Commencez par penser à toutes vos données en tant qu’atsortingbut.
    • Regrouper logiquement les atsortingbuts en éléments. Si vous connaissez vos données, vous aurez rarement besoin de convertir l’atsortingbut en élément. Vous savez probablement déjà quand un élément (collecte ou données répétées) est nécessaire
    • Regrouper les éléments de manière logique
    • Lorsque vous rencontrez le cas, vous devez développer, append de nouveaux éléments / atsortingbuts en fonction de la structure logique d’un processus ci-dessus. L’ajout d’une nouvelle collection d’éléments enfants ne “cassera” pas votre conception et sera plus facile à lire au fil du temps.

    Par exemple, en regardant une collection simple de livres et de personnages majeurs, le titre n’aura jamais “d’enfants”, c’est un élément simple. Chaque personnage a un nom et un âge.

                

    Vous pourriez soutenir qu’un livre pourrait avoir plusieurs auteurs. OK, développez simplement en ajoutant de nouveaux éléments auteurs (supprimez éventuellement le @author original). Bien sûr, vous avez brisé la structure d’origine, mais dans la pratique, c’est assez rare et facile à contourner. Tout consommateur de votre XML original qui suppose un seul auteur devra changer de toute façon (il est probable qu’il modifie sa firebase database pour déplacer l’auteur d’une colonne de la table ‘book’ vers une table ‘author’).

            

    J’ai utilisé Google pour rechercher la question exacte. J’ai d’abord atterri sur cet article, http://www.ibm.com/developerworks/library/x-eleatt/index.html . Bien que cela paraisse trop long pour une simple question en tant que telle. Quoi qu’il en soit, j’ai lu toutes les réponses sur ce sujet et je n’ai pas trouvé de résumé satisfaisant. En tant que tel, je suis retourné à ce dernier article. Voici un résumé:

    Quand dois-je utiliser des éléments et quand utiliser des atsortingbuts pour présenter des informations?

    • Si l’information en question peut être elle-même marquée d’éléments, mettez-la dans un élément.
    • Si les informations conviennent à la forme d’atsortingbut, mais peuvent se retrouver sous la forme d’atsortingbuts multiples du même nom sur le même élément, utilisez plutôt des éléments enfants.
    • Si les informations doivent figurer dans un type d’atsortingbut standard de type DTD, tel que ID, IDREF ou ENTITY, utilisez un atsortingbut.
    • Si les informations ne doivent pas être normalisées pour les espaces blancs, utilisez des éléments. ( Les processeurs XML normalisent les atsortingbuts de manière à modifier le texte brut de la valeur de l’atsortingbut.)

    Principe du contenu de base

    Si vous considérez que les informations en question font partie du matériel essentiel exprimé ou communiqué dans le XML, placez-le dans un élément. Si vous considérez que les informations sont périphériques ou accessoires à la communication principale, ou sont uniquement destinées à aider les applications à traiter la communication principale, utilisez des atsortingbuts.

    Principe de l’information structurée

    Si les informations sont exprimées sous une forme structurée, en particulier si la structure peut être extensible, utilisez des éléments. Si les informations sont exprimées sous forme de jeton atomique, utilisez les atsortingbuts.

    Principe de lisibilité

    Si les informations sont destinées à être lues et comsockets par une personne, utilisez des éléments. Si l’information est plus facilement comprise et digérée par une machine, utilisez des atsortingbuts.

    Principe de liaison élément / atsortingbut

    Utilisez un élément si vous souhaitez que sa valeur soit modifiée par un autre atsortingbut. [..] c’est presque toujours une idée terrible de faire modifier un atsortingbut par un autre.

    Ceci est un bref résumé des éléments importants de l’article. Si vous souhaitez voir des exemples et une description complète de chaque cas, reportez-vous à l’article original.

    Mappage du modèle d’atsortingbuts. Un ensemble d’atsortingbuts sur un élément est isomorphisé directement sur une carte de nom / valeur dans laquelle les valeurs sont du texte ou tout type de valeur sérialisable. En C #, par exemple, tout object Dictionary peut être représenté sous la forme d’une liste d’atsortingbuts XML et inversement.

    Ce n’est absolument pas le cas avec les éléments. Bien que vous puissiez toujours transformer une carte de nom / valeur en un ensemble d’éléments, l’inverse n’est pas le cas, par exemple:

      value another value a third value  

    Si vous transformez ceci en carte, vous perdrez deux choses: les multiples valeurs associées à key1 et le fait que key1 apparaisse avant key2 .

    La signification de ceci devient beaucoup plus claire si vous regardez le code DOM qui est utilisé pour mettre à jour les informations dans un format comme celui-ci. Par exemple, il est sortingvial d’écrire ceci:

     foreach (ssortingng key in map.Keys) { mapElement.SetAtsortingbute(key, map[key]); } 

    Ce code est concis et sans ambiguïté. Contrastez avec, dites:

     foreach (ssortingng key in map.Keys) { keyElement = mapElement.SelectSingleNode(key); if (keyElement == null) { keyElement = mapElement.OwnerDocument.CreateElement(key); mapElement.AppendChild(keyElement); } keyElement.InnerText = value; } 

    Tout dépend de l’utilisation de XML. Lorsqu’il s’agit principalement d’interfaces entre des logiciels et des machines – tels que les services Web, il est plus facile de faire passer tous les éléments, ne serait-ce que pour des raisons de cohérence (et certains préfèrent cette méthode, par exemple WCF). Si elle est destinée à la consommation humaine – c’est-à-dire principalement créée et / ou lue par des personnes -, alors une utilisation judicieuse des atsortingbuts peut améliorer considérablement la lisibilité; XHTML en est un exemple raisonnable, ainsi que XSLT et XML Schema.

    Je travaille habituellement sur la base que les atsortingbuts sont des métadonnées , c’est-à-dire des données sur les données. Une chose que j’évite est de mettre des listes en atsortingbuts. par exemple

     atsortingbute="1 2 3 7 20" 

    Sinon, vous avez un niveau d’parsing supplémentaire pour extraire chaque élément. Si XML fournit la structure et les outils pour les listes, alors pourquoi en imposer une autre vous-même.

    Un scénario dans lequel vous pouvez vouloir coder de préférence pour les atsortingbuts concerne la vitesse de traitement via un parsingur SAX. En utilisant un parsingur SAX, vous obtenez un rappel d’élément contenant le nom de l’élément et la liste des atsortingbuts. Si vous aviez utilisé plusieurs éléments à la place, vous obtiendrez plusieurs rappels (un pour chaque élément). La charge de travail / le temps que cela représente sont bien sûr à débattre, mais cela vaut peut-être la peine d’être envisagé.

    Vous ne pouvez pas mettre un CDATA dans un atsortingbut. Dans mon expérience, tôt ou tard, vous allez vouloir placer des guillemets simples, des guillemets doubles et / ou des documents XML entiers dans un “membre”, et si c’est un atsortingbut, vous allez insulter la personne qui a utilisé les atsortingbuts. d’éléments.

    Note: mon expérience de XML a principalement consisté à nettoyer d’autres personnes. Ces personnes semblaient suivre le vieil adage “XML est comme la violence. Si l’utilisation ne résout pas votre problème, alors vous n’avez pas assez utilisé.”

    Ceci est un exemple où les atsortingbuts sont des données sur les données.

    Les bases de données sont nommées par leur atsortingbut ID.

    L’atsortingbut “type” de la firebase database indique ce que l’on s’attend à trouver dans la balise de la firebase database.

        localhost usrhr jobby consol_hr   /home/anthony/products.adb   

    Les points de l’auteur sont corrects (sauf que les atsortingbuts peuvent contenir une liste de valeurs). La question est de savoir si vous vous souciez de ses points.

    C’est à vous.

    C’est à cause de ce genre de déchets que vous devriez éviter w3schools. Si quelque chose, c’est encore pire que les trucs épouvantables qu’ils ont sur JavaScript.

    En règle générale, je suggérerais que le contenu – c’est-à-dire les données qui devraient être consommées par un utilisateur final (qu’il s’agisse d’une lecture humaine ou d’une machine recevant des informations pour le traitement) – soit le mieux contenu dans un élément. Les métadonnées, par exemple un identifiant associé à un élément de contenu mais uniquement de valeur pour un usage interne plutôt que pour l’affichage à l’utilisateur final, doivent figurer dans un atsortingbut.

    Voici une autre chose à garder à l’esprit lors du choix d’un format XML: Si je me souviens bien, les valeurs des atsortingbuts “id” ne doivent pas être toutes numériques, elles doivent respecter les règles pour les noms en XML. Et bien sûr, les valeurs doivent être uniques. J’ai un projet qui doit traiter les fichiers qui ne répondent pas à ces exigences (bien qu’ils soient du XML propre à d’autres égards), ce qui a compliqué le traitement des fichiers.

    Vous pourriez probablement voir le problème de manière sémantique.

    Si les données sont plus étroitement liées à l’élément, ce serait un atsortingbut.

    c’est-à-dire: un identifiant d’un élément, je le mettrais comme un atsortingbut de l’élément.

    Mais il est vrai que l’parsing des atsortingbuts d’un document peut causer plus de problèmes que d’éléments.

    Tout dépend de vous et de la conception de votre schéma.