Live data from Hacker News

New better alterative to XML, JSON and YAML

xenondata.org

1–10 of 148 posts

Re: New better alterative to XML, JSON and YAML

#3
I feel like I've seen countless attempts at this, and this design doesn't seem any better than usual. There's not much in here to justify the design decisions, nor any indication that a parser implementation exists or is even being actively worked on. For something meant to be "Efficient to write by hand", the insistence on tag-like syntax but with "tags" that consist entirely of a single punctuation character, or which have an extra open bracket, seems error-prone. "Leading and trailing newlines and spacing are intuitively removed from scalars as is indenting." is not adequate guidance for something that claims it "can be implemented to be blazingly fast or using a mode-less tokenizer/parser" (and "mode-less" seems like a strong claim for something that appears intended to support arbitrarily nested objects). This isn't what I would call "terse" given the need for closing tags (which also, according to feedback I've received myself before, counts against human-writability), and it's not at all clear why "the [top-level?] document is named" is advantageous.

Re: New better alterative to XML, JSON and YAML

#7
post #3

I feel like I've seen countless attempts at this, and this design doesn't seem any better than usual. There's not much in here to justify the design decisions, nor any indication that a parser implementation exists or is even being actively worked on. For something meant to be "Efficient to write by hand", the insistence on tag-like syntax but with "tags" that consist entirely of a single punctuation character, or wh…

[deleted]
Post reply on HN