4 ms·

XML wasn't a good fit for databases or configuration files, but it was basically inevitable that it would wind up used in those capacities. Playing around with

XML wasn't a good fit for databases or configuration files, but it was basically inevitable that it would wind up used in those capacities. Playing around with new technology and misusing it in fun ways like that is an important part of the growth of a new technology--that's how we learn what the strengths and weaknesses of a technology are.

bsg75 14y ago
How did the trend develop, especially for things like configuration data? Some warped sense of ease from using Java and .NET libraries to read / write XML?
- fusiongyro 14y ago
  "Warped"? Java didn't exactly have built-in JSON libraries in 1999. The plethora of alternatives manifested largely as a response to the complexity and weight of using an XML parser. Prior to XML you mostly rolled your own parser by hand, use lex/yacc or (if you were using Lisp) used s-exps. Compared to the first two options XML still has a number of meaningful benefits: uniform parsing across languages, uniform validation, and proper handling of encodings. Those aren't anything to sneeze at. "Unicode everywhere" is a fairly new phenomenon (and XML is partly to thank for that), even if Unicode isn't. And different Lisps handle encodings differently as well.
  - bsg75 14y ago
    I chose the term warped as at some point it seemed like XML was used for _everything_, in many use cases the problem was warped to fit an XML solution. For example, simple configuration data made less readable via a poor fit of XML, and the excessive number of these cases. One of my favorite sayings is still "XML is like violence. If it does not solve the problem, you are not using enough."
    - fusiongyro 14y ago
      My favorite is "XML is something you inflict on others, never yourself."
- metajack 14y ago
  As someone who wrote an XML config file for a project way back when, I can provide a few answers. For me, it was either use an off the shelf parser or write my own. The config files at the time were all like apache's config - various combinations of weird syntax. XML came with parsers off the shelf and gave you some validation up front. If there were other tools at the time available, I probably hadn't found them, and XML had a lot of buzz so it was easy to find. These days all the libraries have parsers for a variety of easy to use data formats, from JSON and YAML to Protobufs and ini files.
- MichaelGG 14y ago
  XML is still a good solution for human-readable data. JSON, for instance, doesn't allow comments because of some dogmatic idea of the author. The author of JSON even goes as far as suggesting that you use a non-JSON parser to strip out comments before parsing. In other words, not using JSON for configuration files that need comments.[1] XML is also very ubiquitous in library support, having been around for over 15 years. I think the most negative reaction to XML is the extreme overuse for things like component configuration, where there's no defaults, and every property and class name must be specified. Also, the misguided tag closing (<tag>content</> would have sufficed) adds to the verbosity. 1: https://plus.google.com/118095276221607585885/posts/RK8qyGVaGSr https://plus.google.com/118095276221607585885/posts/RK8qyGVa...
  - bsg75 14y ago
    > XML is still a good solution for human-readable data Urgh... maybe the data I have had the misfortune of working with are not exercising the proper options. The ratio of metadata to data always seems too high. Overuse is likely the cause of my dislike.
  - mnarayan01 14y ago
    God knows something to ease the closing tag verbosity would make XML at least twice as useable. I wonder if there's anything in the grammar that would conflict with </> as a closing tag? I'm almost tempted to muck with libxml and add it for personal use.
    - fusiongyro 14y ago
      A personal dialect of XML? Wouldn't you be better off making your own grammar from scratch?
      - mnarayan01 14y ago
        If I installed it at the system level, then anything that linked against libxml/libxml2 would have the enhancement. Which is also the biggest reason I'm not going to do it...I'd invariably end up distributing XML with the sugarfied close tag.
- Vivtek 14y ago
  No. XML was the first serialization language with widely available drop-in libraries at all - it essentially pioneered that concept. As such, it was a freaking Godsend in the late 90's or so. Believe me, the ability to just link in expat and never have to worry about data serialization from C was so liberating you can't imagine it. (To me, anyway.)
mnarayan01 14y ago
For any non-flat configuration file XML is far from a bad choice. It obviously has its issues, often YAML or something less syntactically burdensome might be better, but I'd need to hear a convincing argument before I would say that it's always the "wrong" choice for configuration files.
- fusiongyro 14y ago
  It's not always wrong, but you have to weigh the advantages against the disadvantages. If you want mechanical editing or syntactic validation it's an advantage. I don't like hand-editing launchd configuration files, but it's helpful that software can ship with launchd configuration files to be installed and it all just works. On the other side of the coin, if there's a lot of scripting going on in the configuration file, the XML will either become burdensome to write or it will wind up carrying around big strings with their own syntax buried within the elements, circumventing the whole point of using XML.
danieldk 14y ago
XML wasn't a good fit for databases or configuration files Except where the database is used to index a collection of XML data. E.g. we store dependency graphs (the output of a natural language parser) in an XML database (Berkeley DB XML), which allows us to quickly select a subset of interesting parses using XPath queries. Sure, we could use a different storage format and query language. But there are good XML databases and XPath is well-known and standardized. The actual XML is normally only touched by machines.
- fusiongyro 14y ago
  I should be more clear: XML isn't a good fit for all databases, but it should be understood that if you're mainly storing and querying XML, an XML database ought to be a better choice.

bsg75 14y ago

How did the trend develop, especially for things like configuration data? Some warped sense of ease from using Java and .NET libraries to read / write XML?

fusiongyro 14y ago
"Warped"? Java didn't exactly have built-in JSON libraries in 1999. The plethora of alternatives manifested largely as a response to the complexity and weight of using an XML parser. Prior to XML you mostly rolled your own parser by hand, use lex/yacc or (if you were using Lisp) used s-exps. Compared to the first two options XML still has a number of meaningful benefits: uniform parsing across languages, uniform validation, and proper handling of encodings. Those aren't anything to sneeze at. "Unicode everywhere" is a fairly new phenomenon (and XML is partly to thank for that), even if Unicode isn't. And different Lisps handle encodings differently as well.
- bsg75 14y ago
  I chose the term warped as at some point it seemed like XML was used for _everything_, in many use cases the problem was warped to fit an XML solution. For example, simple configuration data made less readable via a poor fit of XML, and the excessive number of these cases. One of my favorite sayings is still "XML is like violence. If it does not solve the problem, you are not using enough."
  - fusiongyro 14y ago
    My favorite is "XML is something you inflict on others, never yourself."
metajack 14y ago
As someone who wrote an XML config file for a project way back when, I can provide a few answers. For me, it was either use an off the shelf parser or write my own. The config files at the time were all like apache's config - various combinations of weird syntax. XML came with parsers off the shelf and gave you some validation up front. If there were other tools at the time available, I probably hadn't found them, and XML had a lot of buzz so it was easy to find. These days all the libraries have parsers for a variety of easy to use data formats, from JSON and YAML to Protobufs and ini files.
MichaelGG 14y ago
XML is still a good solution for human-readable data. JSON, for instance, doesn't allow comments because of some dogmatic idea of the author. The author of JSON even goes as far as suggesting that you use a non-JSON parser to strip out comments before parsing. In other words, not using JSON for configuration files that need comments.[1] XML is also very ubiquitous in library support, having been around for over 15 years. I think the most negative reaction to XML is the extreme overuse for things like component configuration, where there's no defaults, and every property and class name must be specified. Also, the misguided tag closing (<tag>content</> would have sufficed) adds to the verbosity. 1: https://plus.google.com/118095276221607585885/posts/RK8qyGVaGSr https://plus.google.com/118095276221607585885/posts/RK8qyGVa...
- bsg75 14y ago
  > XML is still a good solution for human-readable data Urgh... maybe the data I have had the misfortune of working with are not exercising the proper options. The ratio of metadata to data always seems too high. Overuse is likely the cause of my dislike.
- mnarayan01 14y ago
  God knows something to ease the closing tag verbosity would make XML at least twice as useable. I wonder if there's anything in the grammar that would conflict with </> as a closing tag? I'm almost tempted to muck with libxml and add it for personal use.
  - fusiongyro 14y ago
    A personal dialect of XML? Wouldn't you be better off making your own grammar from scratch?
    - mnarayan01 14y ago
      If I installed it at the system level, then anything that linked against libxml/libxml2 would have the enhancement. Which is also the biggest reason I'm not going to do it...I'd invariably end up distributing XML with the sugarfied close tag.
Vivtek 14y ago
No. XML was the first serialization language with widely available drop-in libraries at all - it essentially pioneered that concept. As such, it was a freaking Godsend in the late 90's or so. Believe me, the ability to just link in expat and never have to worry about data serialization from C was so liberating you can't imagine it. (To me, anyway.)

mnarayan01 14y ago

For any non-flat configuration file XML is far from a bad choice. It obviously has its issues, often YAML or something less syntactically burdensome might be better, but I'd need to hear a convincing argument before I would say that it's always the "wrong" choice for configuration files.

fusiongyro 14y ago
It's not always wrong, but you have to weigh the advantages against the disadvantages. If you want mechanical editing or syntactic validation it's an advantage. I don't like hand-editing launchd configuration files, but it's helpful that software can ship with launchd configuration files to be installed and it all just works. On the other side of the coin, if there's a lot of scripting going on in the configuration file, the XML will either become burdensome to write or it will wind up carrying around big strings with their own syntax buried within the elements, circumventing the whole point of using XML.

danieldk 14y ago

XML wasn't a good fit for databases or configuration files Except where the database is used to index a collection of XML data. E.g. we store dependency graphs (the output of a natural language parser) in an XML database (Berkeley DB XML), which allows us to quickly select a subset of interesting parses using XPath queries. Sure, we could use a different storage format and query language. But there are good XML databases and XPath is well-known and standardized. The actual XML is normally only touched by machines.

fusiongyro 14y ago
I should be more clear: XML isn't a good fit for all databases, but it should be understood that if you're mainly storing and querying XML, an XML database ought to be a better choice.