JSON en XML : éléments racine, tableaux et noms de balises non valides

Le tableau sans nom — un tableau JSON de niveau supérieur qui doit devenir un document XML à racine unique et l'élément wrapper qui apparaît

JSON peut commencer par `[1,2]` ; XML ne peut pas commencer par deux éléments de document homologues. ToolAcre encapsule donc un tableau racine dans le nom racine sélectionné et écrit chaque membre en tant qu'enfant `<item>` répété. L'avertissement nomme cette convention, car les noms du wrapper et des éléments n'étaient pas présents dans la source.

Choisir `numbers` donne un élément de document `<numbers>` contenant deux éléments d'élément. La conversion est déterministe, mais pas canonique : un autre système pourrait nécessiter `<number>` ou une collection portant des attributs. Définissez délibérément la racine et comparez le résultat avec le contrat XML requis par le destinataire.

XML a besoin d'exactement une racine - pourquoi chaque conversion invente ou demande un nom d'élément racine

Un document XML doit avoir exactement un élément racine. Un objet JSON avec exactement une clé ordinaire de niveau supérieur peut utiliser cette clé directement. Un objet, un tableau, un scalaire ou un null à plusieurs clés n'a pas de nom unique fourni, donc l'auteur le met entre `root` à moins que l'utilisateur ne fournisse un autre nom légal.

La règle wrapper est implémentée avant la sérialisation et apparaît sous forme d'avertissement. Il n'est pas découvert par un schéma et ne prétend pas que `<root>` a une signification pour le service hérité. Nommer l'enveloppe fait partie de la conception de l'intégration, tandis que le convertisseur ne garantit une structure bien formée que sous son propre mappage.

Les tableaux n'ont pas d'équivalent XML - répétant un élément par élément et comment les tableaux de scalaires et les tableaux de tableaux sont représentés

Les tableaux deviennent des éléments répétés. À la racine du document, les membres utilisent `<item>` sous le wrapper. À l'intérieur d'un objet, un tableau stocké sous `line` devient des frères et sœurs répétés `<line>`. Les tableaux d'objets créent des éléments répétés avec des champs enfants ; Les tableaux imbriqués n'ont pas de nom de domaine et héritent de la structure générique produite par le constructeur.

Cela perd la distinction entre un membre du tableau et un scalaire avec le même nom d'élément après une lecture ultérieure de XML-to-JSON. XML fournit des occurrences, pas un marqueur de tableau indépendant. Si une cardinalité stable est importante, un schéma ou un mappage d'application doit la fournir ; un sérialiseur générique ne peut pas le prouver uniquement à partir des noms d'éléments en forme de JSON.

Clés qui ne peuvent pas être des noms d'éléments : noms commençant par un chiffre, contenant des espaces ou des signes de ponctuation, ou commençant par « xml », et comment les convertisseurs les renomment ou les échappent

Le plan suggère que les convertisseurs peuvent renommer ou échapper aux clés illégales. ToolAcre les refuse explicitement. Une clé avec un espace, une commençant par un chiffre ou un trait d'union, ou une commençant par les lettres réservées `xml` déclenche `UNSUPPORTED_SHAPE` et nomme le chemin incriminé. Renommer silencieusement produirait XML qui ne correspond à aucun schéma convenu.

Les noms valides peuvent commencer par une lettre, un trait de soulignement ou un préfixe de style espace de noms et peuvent contenir des chiffres, des points, des traits de soulignement, des deux-points et des traits d'union après le début. Les clés d'attribut utilisent `@` uniquement comme convention JSON ; le nom d'attribut restant doit passer le même contrôle. Renommez intentionnellement la clé source ou choisissez un autre format cible.

Les clés qui ne peuvent pas être des noms d'éléments sont refusées, jamais renommées ou échappées

Les nombres et les booléens sont sérialisés en tant que texte d'élément, donc leur type JSON n'est plus déclaré par XML. Le lecteur inversé par défaut renvoie par conséquent des chaînes. Null n'a pas de représentation XML ici : il devient un élément vide, impossible à distinguer d'une chaîne vide, et l'écrivain indique combien de valeurs ont subi ce changement.

Cela signifie que `{ "a": null, "b": "" }` peut produire deux éléments vides qui se lisent de la même manière. Appeler cet aller-retour sans perte serait faux. Les attributs `#text` et `#cdata` préservent la convention structurelle du convertisseur, mais ils n'ajoutent pas de système de types général XML.

Les types deviennent du texte XML, tandis que null devient une ambiguïté admise d'élément vide

Utilisez `{"order":{"@id":"A-7","customer":"Ada","line":[{"sku":"P1","qty":2},{"sku":"P2","qty":1}],"note":null}}`. La clé unique `order` devient la racine, `@id` devient un attribut, chaque objet ligne devient un `<line>` répété et null devient un `<note></note>` vide avec un avertissement.

Relisez la sortie avec l'inférence désactivée. L'identifiant d'attribut, la quantité et les valeurs de texte sont des chaînes et la ligne est un tableau car elle apparaît deux fois. Cela démontre l’inverse exact pris en charge tout en exposant les types nuls et numériques perdus. Un schéma d'ordre de réception peut exiger d'autres noms ou ordres, que cet exemple ne valide pas.

Ce que cela ne couvre pas : produire XML qui correspond à un XSD ou un espace de noms donné, qui nécessite un mappage écrit à la main

L'écrivain ne consomme pas de XSD, n'attribue pas d'URI d'espace de noms et ne décide pas de l'ordre des éléments à partir d'un schéma métier. Il écrit une déclaration XML et n'émet jamais de DOCTYPE. Les clés contenant des préfixes d'espace de noms sont conservées littéralement, mais cela ne constitue pas une résolution d'espace de noms ni une preuve que le préfixe est déclaré correctement.

La génération de XML acceptée par un service spécifique peut nécessiter des attributs, des contraintes de séquence, des groupes de choix et des noms qualifiés. Utilisez son schéma ou sa documentation actuelle pour créer ce mappage. Une conversion générique convient à l'inspection et aux documents simples centrés sur les données, et ne remplace pas la sérialisation sensible aux contrats.

À retenir : prédisez la forme avant d'en dépendre - et comment le panneau des convertisseurs de syntaxe montre la structure XML produite par un document JSON

Prédisez l'enveloppe, les noms d'éléments et la perte de type avant en fonction du résultat. ToolAcre encapsule les valeurs dépourvues d'une racine, répète les tableaux, mappe les clés `@` aux attributs, remplace null par du texte vide et refuse les noms illégaux plutôt que de deviner les remplacements. Chaque changement non évident apparaît dans la sortie ou les avertissements.

Testez le plus petit objet qui comprend un tableau de niveau supérieur, des enregistrements répétés, un texte nul, numérique et une clé maladroite. Un refus est une preuve utile qu’une cartographie manuelle est requise. Un fichier réussi doit toujours être validé par le destinataire réel, car XML bien formé et XML valide selon le schéma sont des revendications différentes.

Une fois que le destinataire a accepté un spécimen, ajoutez une inspection inversée uniquement là où la cartographie est censée survivre. Les attributs et les enfants répétés peuvent faire un aller-retour selon la propre convention de ToolAcre, contrairement aux types nuls et scalaires. L’enregistrement de cette distinction empêche qu’un exemple réussi de chemin heureux soit généralisé à chaque document de commande que votre intégration peut produire.