006b9e No.474
I want to store data that will need to be human readable. Is there a better alternative than XML?
4e6082 No.478
json
5bf2ce No.484
json
7600d3 No.487
Json if you want library compatibility, but personally I'm a fan of S-Expressions.
Pulling the code from json.org/example …
{"widget": {
"debug": "on",
"window": {
"title": "Sample Konfabulator Widget",
"name": "main_window",
"width": 500,
"height": 500
},
"image": {
"src": "Images/Sun.png",
"name": "sun1",
"hOffset": 250,
"vOffset": 250,
"alignment": "center"
},
"text": {
"data": "Click Here",
"size": 36,
"style": "bold",
"name": "text1",
"hOffset": 250,
"vOffset": 100,
"alignment": "center",
"onMouseUp": "sun1.opacity = (sun1.opacity / 100) * 90;"
}
}}
!"Also JSON doesn't have comments. This does."
(widget
:debug "on"
:window (
:title "Sample Konfabulator Widget"
:name "main_window"
:width 500
:height 500)
:image (
:src "Images/Sun.png"
:name "sun1"
:hOffset 250
:vOffset 250
:alignment "center")
:text (
:data "Click Here"
:size 36
:style "bold"
:name "text1"
:hOffset 250
:vOffset 100
:alignment "center"
:onMouseUp "sun.opacity = (sun.opacity / 100) * 90;"))
4d6ef0 No.507
>>487I would say sexps are much more readable than JSON. Seriously, look at all those quotation marks.
Anyway, XML isn't that bad. It may certainly be harder to parse, but as long as you use attributes it will be pretty clean and even lightweight, at least on storage.
006b9e No.510
What about YAML?
7600d3 No.511
>>510YAML claims to be human readable, but it also has an 84 page spec
http://yaml.org/spec/1.2/spec.pdf, so I'm inclined to disagree.
9f2f5d No.535
>>487What makes S-Expressions incompatible? They're even simpler to parse than JSON.
9f2f5d No.536
>>487And why is every symbol prepended with a colon?
4d6ef0 No.551
>>511Was YAML that markup language that was like "this is this language's syntax, but you can also write it like this, like that, we also made 9001 ways to perform a specific task, we also have this for redundant redundancy…".
Yeah, fuck that. I tried looking into it when I had a data storage format crisis like OP and was totally disgusted by it. It was clear S-Exps were the best format by far, but chances are it's a pain in the ass to find some parser library for it.
>>536Probably to mark it's a key and not a value. Notice it doesn't close statements, it just opens them.
7600d3 No.552
>>535Yeah, but in most languages you have to program that yourself. Still, it's easily doable in 250 lines or less.
>>536>>551It's to mark keys.
337fd8 No.558
What about SXML?
ec6ed2 No.562
http://openddl.org/This looks very interesting.
I might start using it instead of JSON
ed428b No.563
>>551Why can't the keys be simple unquoted symbols?
4d6ef0 No.567
>>563Because you might want to make a value something else than a string.
For example
(widget
:value 5
:value2 1.9
:value3 a
:378 (
:otherkey "Ass"
:4 "Tits"))
This of course depends on your parser implementation, but it shows why it is done this way.
On top of that, the top value is not marked with : because it is not an "attribute", thinking in XML terms.
1f09b6 No.589
>>562It supports the same types C supports and lacks extensibility. This will inevitably lead to serialising things in a string and suddenly your pretty data files look horrible again.
1f09b6 No.592
>>567What makes XML infinitely better for data than S-Expressions is the fact that it's well structured. If you forget a ) it could go anywhere. If you forget a closing tag, the parser knows exactly where the error is.
What makes XML infinitely worse however, is the fact that one single wrongly encoded character throws off the parser like the raging cisfag it is. You needed that document? Ah that's too bad, I can't recognise this here character so the entire document is deemed invalid.
JSON wasn't meant to be human readable so there's that.
Then there's ASN.1 which will make your head explode, unless you're a government agency.
If you have only tabulated data, TSV is easiest. If you have graphs, OGDL. If you don't care about your data, YAML. If you're going to feed it into other systems, XML. If you live in the 80s, tag-valid SGML.
7600d3 No.594
>>592>If you forget a closing tag, the parser knows exactly where the error is.This is a big part of why I actually hate XML. The XML spec leaves open so much room for parsers to do the wrong thing. If my XML isn't well formed, I want my parser to fail. A format that forces that is one I can respect.
C#'s XML especially loses points for having
<thing value="foo" />
register the same as
<thing>foo</thing>
.
1f09b6 No.595
>>594You hate XML because your parser is non-compliant?
Makes perfect sense.
7600d3 No.605
>>595>non-compliant?No, see, that's the problem.
That's not non-compliant.
XML doesn't specify how you handle attributes named "value", which is an issue because the area between two tags is also a value.
1f09b6 No.606
>>605The whitespace between tags are textNodes and iirc msxml has a way of filtering those out, so you should be fine
1f09b6 No.607
>>605>>606oh wait
>>594Dang, looks like someone fucked up an API
Perhaps if you grab an alternate api with nuget? You're not likely to be the first to deal with this
7f9bd8 No.627
>>567Why not:
(widget
value 5
value2 1.9
value3 a
378 (otherkey "Ass" 4 "Tits"))
?
7f9bd8 No.628
>>592>If you forget a )We're talking about serialization protocols. Your program isn't going to forget a bracket. And anyone using a good text editor has automatic bracket matching.
1f09b6 No.630
>>628See
>>474>I want to store data that will need to be human readableYou have to factor in the probability that a human will want to make edits/author additional data. XML and YAML are fine candidates for the stated purpose. I'd prefer the cleanliness of YAML over the verboseness of XML, personally. (Both over s-expressions.)
7f9bd8 No.641
>>630>You have to factor in the probability that a human will want to make edits/author additional data
>And anyone using a good text editor has automatic bracket matching.You can make a visual tree data editor if you want. S-Expressions make it extra simple.
>YAMLRuby guy?
7600d3 No.648
>>627
(object
:name "Example"
:value (list
a
b
C))
eb828e No.651
>>648(object
name "Example"
value (a b C))
b750ba No.653
>>651Is this actually lexed and parsed as data or do you read this by feeding it into the lisp interpreter proper?
eb828e No.654
>>653I was under the impression that to read S-Expressions you simply use the Lisp parser, which gives you the actual tree data.
0143d4 No.658
I've looked at a lot of benchmarks and read quite a bit - json seems the fastest and best supported from what i've seen. Most of what I've looked at relates to most of the major databases, javascript, and python. (side note: if i was storing the json in the db I'd most likely store it as text, although i'd also do a lot of research on the particular case)
XML i think is great for, like, hyper-generalized data, or interfacing with xslt. but it can get pretty slow when the xls gets real complicated
7600d3 No.662
>>648
object
…has name ("Example")
…has value (list)
…has a
…has b
…has c
object
…has name
…has "Example"
…has value (list)
…has a
…has b
…has c
Your example is *legal* in the system using :key value, but it's ambiguous. Especially if you're using variables. :foobar wouldn't conflict with a variable name foobar, since it's identified as a field.
eb828e No.666
>>662How is it ambiguous? It's just symbol/key pairs.
If it's such a problem:
(object
(name "Example")
(value (a b C)))
1f09b6 No.668
>>658The slowest available parser on the slowest available computer is going to be several orders of magnitude faster than the human who's going to read the data.
Also, what Knuth said (the optimisation quote was from him IIRC).
7600d3 No.672
>>666
object
…has name
…has "Example
…has value
…has a
…has b
…has c
Again, you've expressed something that's already legal and represents something different.
There's no way to represent both key-value-pairs and list-style-parameters without giving one of them a different syntax. Sorry brah.
2b720e No.673
>>672Why is example inside name?
object
…has name "Example"
…has value
…is a b c
Sure, it's still a list. It's what you make of the list that counts.
7600d3 No.679
>>673Because that's what your data represented.
The first value in the (a b c) form represents the identity of that expression. Everything else is a node. If you want your node to be a key-value pair, it needs additional syntax, otherwise you're just making a different tree.
Think of it like the difference between
<object>
<name>
"Example"
</name>
</object>
and
<object name="Example">
</object>
The :notation signifies keyed values, instead of anonymous values.
7dc2ae No.684
>>679But a key-value pair
is just a different tree.
7600d3 No.685
>>679>>684(object
:foo "bar"
(foo "bar"))
The first notation is preferred for structured data, like mapping fields to a known API. The second is preferred for anonymous data, like lists of arbitrary lengths.
4f9a5a No.1426
ini
b4c685 No.1431
Depends.
For just basic shit, you could just lines; One thing I've done is have a key-value pair for each line, separated by an equals sign. ie:
id=1
name=john smith
address=123 example rd
If you need the hierarchical structure that XML supports, and/or multiple 'records' without needing to use multiple files, I agree with the other posts; you could go with S-expressions or JSON. You'll probably want JSON since I assume you're not using Lisp.
98a470 No.1711
>>510>What about YAML?I think YAML is human readable, but not human-writable. Significant whitespace in a config format? Vomitous.
>XMLThe nice thing about XML is having a schema that can be validated against. Also very good at nested hierarchical data, since it's just a tree in text form. I usually go with JSON, though.
daa74d No.1712
>>658json is massively faster than xml, I know this from many, many experiences. That said, I prefer XML because you can actually define a structure for your data and validate it.
49480d No.1715
TOML
560946 No.1871
>>1426+1 if it's a config file
4383c0 No.2131
tsv master race
bccd7d No.2156
>>487
I wish there was an S-expressions equivalent of xaml with a gui library to go with it. That would be fucking tits.