5 ms·

You say that like you’ve never really used XML... (Mostly /s. Come at me:))

• quotemstr 7y ago
  I've used it quite a bit. I even like the namespacing bits. I find that XML composes elegantly in a way that the JSON and friends don't. My one request would be to bring back to SGML-like closing tag abbreviation: That is, instead of <foo><bar>qux</bar></foo> we should be able to write <foo><bar>qux</></> I think this one change would make XML more "palatable" for the JSON/YAML/TOML crowd.
  • _eht 7y ago
    Interestingly I find SGML-esque to be quite unpalatable. I get the feeling doing code reviews would be nightmarish.
    • quotemstr 7y ago
      Why? It's no worse than S-expressions.
      • WillPostForFood 7y ago
        The verbosity makes it harder to parse. It is subjective, but I find ")))" is a lot easier to instantly parse as 3 than "</></></>"
      • _eht 7y ago
        It’s significantly worse than single char s expression for my eye, anyway.
  • deleted 7y ago
    [deleted]
  • tannhaeuser 7y ago
    SGML also has tag omission to make this even less verbose if desired. Or short references, which basically let you define arbitrary tokens SGML recognizes and replaces into something else, depending on the element context. These techniques in combination can be used to parse s-expr, CSV, markdown, and even some JSON, for example. Though personally I agree with others here that SGML is first and foremost a markup rather than config language.
    • quotemstr 7y ago
      The problem with tag omissions is that it requires that the parser have tag-specific information to properly build the AST. You can still do generic parsing with balanced </>.
  • a1369209993 7y ago
    Or even better: <foo/<bar/qux>> (Although standard SGML inexplicably specifies a null-end-tag character of '/' rather than '>', so this won't work in stock parsers.)
    • meowface 7y ago
      This looks absolutely hideous. I don't see why this would make me want to switch from YAML or JSON.