JSON correspondant à un document XML avec des attributs?

Cette approche soutient la transformation inverse pour XML:

{
    "folders": {
        "folder":{ 
        "@": {
            "id": "123",
            "private": "0",
            "archived": "0",
            "order": "1"
            },
        "#": "Shopping"
        }
    }
}

Il fonctionne correctement avec js2xmlparser.

Un exemple de la façon dont YQL présente XML et JSON correspondant. Pas besoin de savoir quelque chose au sujet de YQL à comprendre cela, mais si vous êtes intéressé, vous pouvez vérifier la YQL de la console et de l'essayer vous-même dans le YQL console

XML

<results>
    <a href="/">NBA</a>
    <a class="topnav" href="#">TEAMS</a>
    <a href="/teams/">Teams</a>
    <a href="/hawks/">Atlanta</a>

JSON

"results": {
  "a": [
    {
     "href": "/",
     "content": "NBA"
    },
    {
     "class": "topnav",
     "href": "#",
     "content": "TEAMS"
    },
    {
     "href": "/teams/",
     "content": "Teams"
    },
    {
     "href": "/hawks/",
     "content": "Atlanta"
    },

Il me semble que la plus de correspondance exacte entre XML et JSON aurait besoin de représenter un nœud XML comme un triplet (c'est à dire array): [nom, les attributs de la valeur], avec le nom d'une chaîne, les attributs d'un objet avec les noms d'attributs que les clés et les valeurs d'attribut (string) des valeurs, et la valeur d'une chaîne de caractères (pour les valeurs atomiques) ou d'un tableau de ces triplets.

Par exemple la cartographie du JSON-l'équivalent de

<folders>
    <folder id="123" private="0" archived="0" order="1">Shopping</folder>
</folders>

serait

[  "folders",
   {}, 
   [
      [  "folder", 
         {   "id": "123",
             "private": "0",
             "archived": "0",
             "order": "1"
         },
         "Shopping"
      ]
   ]
]

En fait l'idée derrière cette cartographie est que:

1) XML-JSON transformation est réversible.
2) Le "frère" de la relation de sous-nœuds être préservée

Dans le même temps, la distinction entre les nœuds de l'attribut et la valeur des nœuds est explicite ici.

T-il un sens? Et elle justifie la complexité dessus?

JSON est plus uniforme que XML et ne fait pas la distinction entre la plaine-des attributs de texte et hiérarchique du contenu. La représentation naturelle de votre exemple serait

[
  {"id": 123, "private": 0, "archived": 0, "order": 1, "name": "Shopping"}
]

C'est encore plus compact que le respectifs XML.

J'ai couru dans un scénario qui a besoin de XML et JSON pour l'entrée et la sortie sur la base de ce qui est passé. J'ai trouvé un moyen qui fonctionne avec des Attributs XML/Propriétés et JSON. Remarquez maintenant, c'est comment il est codé en Java, permet de travailler de cette façon.

Mon XML Exemple:

<Log>
    <datetime>05/05/2017 13:45:22</datetime>
    <sessionid>2da236d2-3852-4a09-8067-198193d2828b</sessionid>
    <message msgType="Debug">This is my message</message>
</Log>

Mon JSON Exemple:

{
    "datetime":"05/05/2017 13:45:22",
    "sessionid":"2da236d2-3852-4a09-8067-198193d2828b",
    "message": {
        "content":"This is a testa",
        "msgType":"Debug"
    }
}

Comment je l'ai fait travailler via le code Log.java:

package log;

import com.fasterxml.jackson.dataformat.xml.annotation.JacksonXmlProperty;
import com.fasterxml.jackson.dataformat.xml.annotation.JacksonXmlRootElement;

@JacksonXmlRootElement(localName = "Log")
public class Log {
    @JacksonXmlProperty(localName = "datetime")
    private String datetime;
    @JacksonXmlProperty(localName = "sessionid")
    private String sessionid;
    @JacksonXmlProperty(localName = "message")
    private Message message;

    public Log() {
        this.sessionid = "0";
        this.datetime = "";
        this.message = new Message();
    }

    public String getDatetime() {
        return datetime;
    }

    public void setDatetime(String datetime) {
        this.datetime = datetime;
    }

    public String getSessionid() {
        return sessionid;
    }

    public void setSessionid(String sessionid) {
        this.sessionid = sessionid;
    }

    public Message getMessage() {
        return message;
    }

    public void setMessage(Message message) {
        this.message = message;
    }
}

Message.java, Note le @JacksonXmlText ci-dessous, qui est la clé:

package log;

import com.fasterxml.jackson.dataformat.xml.annotation.JacksonXmlProperty;
import com.fasterxml.jackson.dataformat.xml.annotation.JacksonXmlText;

public class Message {
    @JacksonXmlProperty(localName = "msgType", isAttribute = true)
    private String msgType;
    @JacksonXmlText
    private String content;

    public Message() {
        this.content = "";
    }

    public String getMsgType() {
        return msgType;
    }

    public void setMsgType(String msgType) {
        switch(msgType.toLowerCase())
        {
        case "test":
        case "debug":
        case "warn":
        case "error":
            break;
        default:
            msgType = "Unknown";
            break;
        }

        this.msgType = msgType;
    }

    public String getContent() {
        return content;
    }

    public void setContent(String content) {
        this.content = content;
    }
}

Appelant au sein LogController.java:

..
@RequestMapping(value = "/Logger", produces={"application/xml", "application/json"}, consumes={"application/xml", "application/json"})
public ResponseEntity<String> Logger(@RequestBody String logInfo, @RequestHeader("Content-Type") String contentType) {
    try 
    {
        String xml = "";
        Log logObj = null; 
        HttpHeaders responseHeaders = new HttpHeaders();
        responseHeaders.add("Content-Type", contentType);

        if (contentType.toLowerCase().contains("json"))
        {
           ObjectMapper mapper = new ObjectMapper();
           logObj = mapper.readValue(logInfo, Log.class);
           xml = mapper.writeValueAsString(logObj);
        }
        else if (contentType.toLowerCase().contains("xml"))
        {
           XmlMapper xmlMapper = new XmlMapper();
           logObj = xmlMapper.readValue(logInfo, Log.class);
           xml = xmlMapper.writeValueAsString(logObj);
        }
        else
           return new ResponseEntity<String>(HttpStatus.BAD_REQUEST);

        //TODO GWL
        //Save Log data, via Async Web Service, Data, or System 
        return new ResponseEntity<String>(xml, responseHeaders, HttpStatus.OK);
    } 
    catch( Exception ex)
    {
        ex.printStackTrace();
        return new ResponseEntity<String>(HttpStatus.BAD_REQUEST);
    }
}

D'ouverture mise en garde: Dans cette réponse, je suis délibérément dans la question d'origine, et l'élargissement de la portée un peu. Parfois poser la question derrière la question que nous avons besoin de regarder la grande image de la première.

Comme tous les animaux sont égaux, toutes les traductions de JSON en XML, et à partir de XML en JSON sont inégales. Il ne peut être mathématiquement correct réponses à cette question, et même si il y a, ils peuvent être faux. Toutes les réponses seront une question d'opinion, et dépendent du exact de cas d'utilisation(s).

JSON et XML à la fois de soutien et d'omettre des concepts qui rendent parfait, réversible et natif de traductions difficile.

Pour en nommer que quelques-uns:

• XML nécessite un élément racine. JSON n'est pas.

• XML fait la distinction entre les Éléments et les Attributs. Les attributs sont des feuilles, des Éléments peut-être des feuilles ou des branches. Objets JSON sont proches des Éléments, mais n'ont pas d'équivalent direct aux Attributs.

• JSON a des tableaux; le plus proche équivalent XML est un Élément parent, mais certaines traductions de tomber sous le coup où il y a un seul élément enfant.

• XML a des espaces de noms..... Le moins dit à propos de ces le mieux...

• JSON est conçu pour être compact et léger, et est plus proche (à mon humble avis) pour YAML que XML.

Où un concept existe dans la langue source, mais pas dans la langue cible, nous devons être inventifs et créatifs dans notre traduction. Vos cas d'utilisation sont la clé.

par exemple

• Sera le résultat en tant que natif du possible dans la langue cible? Aurions-nous le modèle comme ceci JSON? Aurions-nous le modèle comme ceci dans le fichier XML?

• Sera le résultat réversible à la source d'origine, même au détriment des “indigènes se sentent”?

• Est la compacité des critères? Ce peut être le cas pour JSON sur un élément lourd XML, mais pas pour JSON traduit de l'XML et conçu pour être traduit.

Pour faire une comparaison avec les langues humaines: En Suisse allemande, nous aimons notre diminutives: les Noms sont systématiquement réduites pour le petit formulaire où ce serait étrange en anglais; mais encore plus bizarrly, nous avons diminutives de verbes!

Donc: “wir machen es köchele”, pourrait traduire techniquement à la “nous allons cuisiner littely”, ou “nous faire un peu de cuisine”, mais l'un et l'autre être pauvre et incorrect anglais, et en quelque sorte manquer l'idée.

“nous allons faire un peu de cuisine” ou “nous aurons le plaisir de la cuisine” serait beaucoup plus proche de l'idée originale. Mais je soupçonne que Anthea Bell (d'Asterix-aux-anglais traduction de la gloire) serait vraiment obtenir le point; “nous allons cuisiner un festin....”

Revenir à la question initiale. Python pour les programmeurs ont un concept de pythonesque: = la plupart de montage pour le noyau ethos de python. La réponse par user166390 (la accepté de répondre au moment de cette réponse) qui me frappe le plus JSONesque.

Excluant les noms d'attributs qui sont toujours à la même longueur, JSON sera toujours plus compact que le juste n'ont pas les balises de fermeture 😉