4 ms·

For those who missed it, here's what Linus wrote in the comments: "+Aaron Traas no, XML isn't even good for document markup. Use 'asciidoc' for document marku

For those who missed it, here's what Linus wrote in the comments: "+Aaron Traas no, XML isn't even good for document markup. Use 'asciidoc' for document markup. Really. It's actually readable by humans, and easier to parse and way more flexible than XML. XML is crap. Really. There are no excuses. XML is nasty to parse for humans, and it's a disaster to parse even for computers. There's just no reason for that horrible crap to exist. As to JSON, it's certainly a better format than XML both for humans and computers, but it ends up sharing a lot of the same issues in the end: putting everything in one file is just not a good idea. There's a reason people end up using simple databases for a lot of things. INI files are fine for simple config stuff. I still think that "git config" is a good implementation."

edoloughlin 13y ago
Use 'asciidoc' for document markup. I just had a quick scan of the user guide. It's very impressive. Looks like markdown but with all the edge cases thought out.
- buster 13y ago
  I've been working with restructured Text a lot, it's a breeze as well. Seems quite similar.
  - e12e 13y ago
    Just a note, pandoc (implemented in Haskell) makes it almost a joy to work with various "dialects" of ReST/AsciiDoc/Markdown etc. It feels like what python's ReST should have been (at least the last time I looked, it was pretty hard to get different html out of it - even if it is supposed to be extendible). If you have a dependency on python, staying with the python libs are probably best, but if you just want "a document system", I recommend having a look at pandoc.
    - buster 13y ago
      Actually, i am using sphinx and latexpdf to generate project documentation and it is more then awesome to generate beautiful looking LaTeX documents with graphiz graphs in high-res but only writing rst... :)
bhaak 13y ago
Linus' adversion to XML explains also why parsing git's output is so abysmal inconsistent. Subversion has a really good XML output for its log command which is a joy to use (and that's something to say if you work with XML) whereas with git you always have ugly format options that are most of the time underdocumented.
- davvid 13y ago
  I disagree. It's actually quite simple, and fast. Git's output was designed in the Unix spirit; you can parse it very quickly without needing a parser toolchain. It's also extensively documented: git help log, etc
72deluxe 13y ago
I think he overuses the single-word sentence "really" too much. Really.
saraid216 13y ago
> in the end: putting everything in one file is just not a good idea. There's a reason people end up using simple databases for a lot of things. I'd really like to hear more about this perspective, if anyone feels like they can elaborate.
underwater 13y ago
I like that the syntax for features is illustrative, so that the raw text representation doesn't end up as a mess of ugly tags. However it looks completely inflexible. It's a mishmash of special cases. How would I implement a new feature without breaking existing implementations? Or without having to write a new parser that in all likelihood will break on some subtle edge case? At its core XML (if you ignore all the DTD, namespace and entity rubbish) is both simpler and more powerful than this. You have text, tags and attributes. What those tags and attributes mean is up to the application, but at the very least you can be sure that the document can always be reliably parsed into a form you can work with.

edoloughlin 13y ago

Use 'asciidoc' for document markup. I just had a quick scan of the user guide. It's very impressive. Looks like markdown but with all the edge cases thought out.

buster 13y ago
I've been working with restructured Text a lot, it's a breeze as well. Seems quite similar.
- e12e 13y ago
  Just a note, pandoc (implemented in Haskell) makes it almost a joy to work with various "dialects" of ReST/AsciiDoc/Markdown etc. It feels like what python's ReST should have been (at least the last time I looked, it was pretty hard to get different html out of it - even if it is supposed to be extendible). If you have a dependency on python, staying with the python libs are probably best, but if you just want "a document system", I recommend having a look at pandoc.
  - buster 13y ago
    Actually, i am using sphinx and latexpdf to generate project documentation and it is more then awesome to generate beautiful looking LaTeX documents with graphiz graphs in high-res but only writing rst... :)

bhaak 13y ago

Linus' adversion to XML explains also why parsing git's output is so abysmal inconsistent. Subversion has a really good XML output for its log command which is a joy to use (and that's something to say if you work with XML) whereas with git you always have ugly format options that are most of the time underdocumented.

davvid 13y ago
I disagree. It's actually quite simple, and fast. Git's output was designed in the Unix spirit; you can parse it very quickly without needing a parser toolchain. It's also extensively documented: git help log, etc

72deluxe 13y ago

I think he overuses the single-word sentence "really" too much. Really.

saraid216 13y ago

> in the end: putting everything in one file is just not a good idea. There's a reason people end up using simple databases for a lot of things. I'd really like to hear more about this perspective, if anyone feels like they can elaborate.

underwater 13y ago

I like that the syntax for features is illustrative, so that the raw text representation doesn't end up as a mess of ugly tags. However it looks completely inflexible. It's a mishmash of special cases. How would I implement a new feature without breaking existing implementations? Or without having to write a new parser that in all likelihood will break on some subtle edge case? At its core XML (if you ignore all the DTD, namespace and entity rubbish) is both simpler and more powerful than this. You have text, tags and attributes. What those tags and attributes mean is up to the application, but at the very least you can be sure that the document can always be reliably parsed into a form you can work with.