5 ms·

> XML is easily translatable to JSON Not really. XML is a document markup language, where order is important. JSON is a serialization format, and is a bit more

• deleted 11y ago
  [deleted]
• skissane 11y ago
  There are many ways to do it, you just need to pick a convention. For example, one convention is that you use "#" as key for element name, "." as key for element children, and attribute name as keys for the attributes. Following those conventions, you can produce: { "#" = "foo", "bar" = "baz", "." = [ { "#" = "bork", "." = "foo1" }, { "#" = "bork", "." = "foo2" } ] } Or, for something more verbose (but maybe more intelligible), you could use "$element" as key for element names, and "$children" as key for child elements / text. (The point of choosing $ as a prefix, is it is not a valid character in attribute names, so cannot conflict with them.)
  • Zikes 11y ago
    That is pretty hard for a human to parse and understand, though. I think it could be reasonably easy to come up with a config file standard in XML or JSON, but that the format will have to rely on the strengths of each. Translating between the two just becomes an unreadable mess. If anything, if I were to write an application that allowed for either format, I would come up with a separate standard for each. More code/upkeep, but when the config files are intended for humans and to be hand-written, the focus should be on the user.
    • pen2l 11y ago
      JSON is not all that readable for a human either, if that was the main complaint. I guess let me just ask this: Why does XML suck?
      • librvf 11y ago
        It's not just readability. XML has some serious issues when used as a configuration file format rather than as document markup. It has features oriented towards document markup that get in the way of writing data structures, and it lacks convenient features for writing data structures that yaml-like languages have. First, a quick disclaimer: Apache conf format is not really XML. It leverages XML-like syntax but it's mostly not XML and avoids most of the serious problems that XML tends to bring, which I'll explain in more detail below. XML was designed to provide structure to documents, it was not designed as a configuration syntax or a data serialization format. XML is meant for a document that already exists in its own right as a document, where the XML is added on as a layer to aid automated semantic understanding of that document's structure. It is not meant to directly represent programming data structures. As such, XML tags are designed to pop out and be visible from significant amounts of text that is not metadata. When there's more tags than text, as is usually the case when you try to use XML to write programming data structures, XML winds up being hopelessly verbose, and it's hard to avoid errors writing it (like misspelling end tags, forgetting a slash, putting end tags in the wrong order, etc.) When not used for its intended purpose, XML winds up being hard for humans to write directly and hard(er than yaml and json) to write programs to parse it. In yaml and json, there's a standard, mostly direct mapping to common data structures in most high-level languages. With XML you have to make a lot of trivial decisions to make use of features that weren't designed for what you're trying to do. The most obvious examples are the distinction between attributes and tags: what does each one mean? What do tagnames represent? What do attribute values represent? What do attribute names represent? How do you handle CDATA that has more XML in it? XML is designed to elegantly handle something like this: <A>first section <B>marked up section</B> second section</A> But this kind of structure is horrible for a configuration file, unless the CDATA sections are a parsed language of their own and parsed externally, which is essentially what Apache does. If you're trying to use XML to specify data structures like lists and trees, it's messy. Consider this example: <VirtualHost> <ServerName>my.server.domain.com</ServerName> <DocumentRoot>/var/lib/www/my.server.domain.com</DocumentRoot> </VirtualHost> You might envision "VirtualHost" to be an item in a list, where the value of that item is a dictionary with subkeys specifying "ServerName" and "DocumentRoot." But in fact, there's more to it than that. An XML parser also gives you all the whitespace in between those two tags. You can discard it, you can write checks to ensure that nothing ever ends up in that unused CDATA area by mistake, you can write tools to generate the XML-- but no matter what method you choose it's something you have to think about that just doesn't come up if you are using a language designed for writing programming data structures instead of abusing one designed for marking up text documents. And that example highlights another problem with XML which is a flat out lack of support for common programming data types such as lists and integers. In the example above, how would you know that "<VirtualHost>" represents an item in a list, but "<ServerName>" should be a key in a dictionary? XML doesn't help you there, every parser decides for itself.
  • librvf 11y ago
    > There are many ways to do it, you just need to pick a convention. The fact that you have to pick a convention is the crux of the issue. "Easy" is a subjective term, but the fact is there isn't a direct mapping between XML And JSON. It means that if you're using XML and converting it into a programming data structure, you have to make a bunch of decisions about how to handle the XML. It means that if you're converting a programming data structure to XML, you have to have a bunch of specific rules for how to generate that XML. With JSON, you only have to make those decisions if you need to use data structures that aren't supported by JSON.