4 ms·
And how is this better than xml? <owner name="Tom Preston-Werner" organization="GitHub" bio="GitHub Cofounder & CEO\nLikes tater tots a
by dfkf 14y ago
And how is this better than xml?
<owner name="Tom Preston-Werner"
organization="GitHub"
bio="GitHub Cofounder & CEO\nLikes tater tots and beer."
dob="1979-05-27T07:32:00Z" />
<database server="192.168.1.1"
ports="8001 8001 8002"
connection_max="5000"
enabled="true" />
<servers>
<alpha ip="10.0.0.1"
dc="eqdc10" />
<beta ip="10.0.0.2"
dc="eqdc10" />
</servers>
- jaequery 14y agoplease let's not bring XML into this. last thing we need is someone inspired to say let's all go back to XML.
- dfkf 14y agoGo "back"?! There are lots of places where xml is alive and well and config files is one of them. And you can see why - empty elements with attributes look rather concise, and without all that punctuation noise JSON has.
- MichaelGG 14y agoAgree. And if XML supported unnamed closing tags, it'd lose a lot of it's rep for verbosity. Although in this case you'd just be replacing </servers> with </> in other documents it is a lot more noticeable. I will note this isn't a valid XML document: you have no root node.
- icebraining 14y agoLet's see: . No native support for numbers, dates, booleans or lists. The latter can be implemented using subelements, but it's so cumbersome that you skimped on that and used a non-typed string instead (the database ports). . Redundant verbosity. Root elements, closing tags, way too much crap to be manually inserted. . XML parsers are huge, complex beasts which have no place in many smaller applications. . Being XML, it leaves way too many possibilities for crappy developers. Namespaces in config files, oh joy! http://harmful.cat-v.org/software/xml/ http://harmful.cat-v.org/software/xml/
- dfkf 14y agoMost of your points are environment specific and I think that you forgot the strongest of them - "xml APIs usually suck". In .net they are non-issues. And about being cumbersome and verbose, the point I tried to make is that you don't have to be zealous and put every small piece of data in a separate element. No reason not to put data in attributes or even in comma/whitespace separated strings, if that piece of data can be extracted in one short line of code.
- icebraining 14y agoMost of your points are environment specific How so? .Net can't magically discover the types of values or prevent developers from abusing the format. you don't have to be zealous and put every small piece of data in a separate element. But then you're layering a complex format with a custom application-specific parser, with an unknown syntax (e.g. spaces vs commas, are ranges supported, etc). It obviously can be done, but it's a mess.