41–50 of 148 posts
It's unlikely, and even if you are right, we won't switch standards, best you can hope is individual adoption, and you can achieve that by offering a tradeoff, improving in one area.
> Readable multiple line indented text. Then > Fascinating. Of interest. Worth reading. Does that look readable to anyone?!
Funnily enough, I've been working on solving the same problem concurrently. Though in my _very_ biased opinion; I think CONL is easier to read and write: https://github.com/ConradIrwin/conl value = example map a = b list = 1 = 2 multiline_value = """bash #!/usr/bin/bash echo "hello world"
> Xenon is the best way to represent information: terse The best would be to remove all the unneeded unergonomic shift-requiring from here, you already have = symbol with whitespace and $ that separate all you need
The example you give is valid xᴇɴᴏɴ. The key and value may contain whitespace and must be delineated? s are that that made XML and HTML good.
[1] Hint: "semi-structured data"
A new better alternative definition of Terse: The act of proclaiming a “new standard” without any user community to speak of.
It has ALL of the advantages of xᴍʟ.
One thing that is also really important is the ability to define a schema and be able to validate. See XML Schema, JSON Schema. This is a really tricky problem to get right. Especially if you try to do both with the same model (describing your data model and describing how its validated) at the same time.
Once you have the schema, IDEs like VSCode offer code-intelligence and real-time validation, which is very nice.
Funnily enough, I've been working on solving the same problem concurrently. Though in my _very_ biased opinion; I think CONL is easier to read and write: https://github.com/ConradIrwin/conl value = example map a = b list = 1 = 2 multiline_value = """bash #!/usr/bin/bash echo "hello world"
Agreed that this is much better than the OP. That said, my general opinion is that a whitespace-only indentation should be avoided especially in the serialization format due to the inherent ambiguity of whitespace characters and resulting human mistakes. When I designed CSON [1] I strived to make it as readable as possible without the indentation for that reason. [1] https://github.com/lifthrasiir/cson
I went with indentation because a very common use-case in a configuration file is commenting out lines. Even with CSON-like comma rules, you still need to balance your {} and []s. Indentation balances itself most* of the time.
as far as readability goes, I’ll stick with Toml (imo, superior to json, xml). xenon: Fredrick Freddy toml: names = [“Fredrick”, “Freddy”]
Sorry, as who have already designed yet another JSON alternative. Many things about this format are just wrong (as of the first edition): - (EDIT: Mistakenly read SHOULD as MUST, ignore this item please) The requirement for the mandatory BOM is unacceptable for most non-Windows users, as BOM is by definition invisible. - An arbitrary name is equally questionable, even XML doesn't do that. Do you accept tabs for examp…
Not entirely sure what you mean with canonical representation (I've heard this in the context of JSON-LD before, though). Can you explain what you mean here?
Where do you see the problem with Graphs and Dos? A reference is just a pointer. You just have to be careful when doing recursive code. I actually like the idea to explicitly define how a reference / association is made, because otherwise people will have to re-invent ID and association concepts and there's no shared understanding. In JSON Schema, you cannot properly express an association or graph structure and people start using overloaded and not well-defined concepts like `$ref` which is a separate standard.
Earlier quoted context omitted.
This is needlessly rude and dismissive, consider that the author of this spec is in the comments responding to people. If he had presented this at a conference would you come up to him after and say this to his face? Try to have a little more decorum when giving feedback
> If he had presented this at a conference would you come up to him after and say this to his face? Is this a fair comparison? I didn't come here by invitation and neither did the author. > Try to have a little more decorum when giving feedback It's not feedback. It's an unexpurgated opinion. We are reading a comment card. It has a value of it's own.
I doubt OP would ever speak in a business environment this way, and if he did those around him would certainly consider it to be harassment and deeply unprofessional.