9 ms·
New better alterative to XML, JSON and YAML
- deleted 2y ago[deleted]
- zahlman 2y agoI 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.
- deleted 2y ago[deleted]
- GeneThomas 2y agoBoth a C# and JavaScript implementations exist. The terse “single punctuation character”, e.g. <$> make it efficient to write, more efficient than JSON. There is no “extra open bracket”? There is a overview of how the indenting operates. Mode-less, means the tokeneizer does not require modes, unlike those required for XML. The parser has state. Have the top level document named allows one to see what the document is, e.g. <Example-Document> or <Person>.
- zahlman 2y ago`<$>` is not simpler than `}`, nor `]`. The array syntax has the "extra open (angle) brackets": in `<<Names> Fredrick <&> Freddy <<$>` we see `<` more often than `>`.
- GeneThomas 2y agoIt is more terse than JSON.
- zahlman 2y agoHave you created any benchmarks to demonstrate this?
- GeneThomas 2y agoSee https://news.ycombinator.com/item?id=42038004#42049033 https://news.ycombinator.com/item?id=42038004#42049033
- necovek 2y agoObligatory XKCD: https://xkcd.com/927/ https://xkcd.com/927/ That page does not support the topic title at all: why is this a "better alternative" to XML, JSON or YAML?
- GeneThomas 2y agoGrudgingly ha ha. As per https://xenondata.org https://xenondata.org Xᴇɴᴏɴ is more terse than even ᴊꜱᴏɴ and has the advantages listed in first paragraph.
- GeneThomas 2y agoI shall elaborate on the first paragraph of the web page: • Terse. Xᴇɴᴏɴ is as terse as ᴊꜱᴏɴ using 3 characters per scalar value <key=value> rather than ”key”:value, (4) or ”key”:”value”, (6). Xᴇɴᴏɴ is significantly more terse than xᴍʟ <key>value</key> (5+len(key)) around 10. • Readable multiple line indented text. ᴊꜱᴏɴ does not support multiple line text, forcing one to escape newlines as ‘\n‘. xᴍʟ looks messy with multiline line text as the text is copied verbatim, indenting is therefore from the left of the page. Xᴇɴᴏɴ allows one to indent text more than the enclosing markup. Native support for arrays Awkward in xᴍʟ. • Native support for a graph structure, elements may have multiple parents. Both missing from ᴊꜱᴏɴ and xᴍʟ where special fields are layers on top of the markup. • Native support for a types used in serialization. Also missing from ᴊꜱᴏɴ and xᴍʟ. • Unambiguous choice of data structure. No attributes. • Efficient to write by hand. see Terse. Also supports comments unlike ᴊꜱᴏɴ. • Can be implemented to be blazingly fast or using a mode-less tokenizer. Design decisions took performance and grammar simplicity into account. • The xenon document is named. Useful. One can see that the document is a <Person> or <Example-Document>
- GeneThomas 2y agoI have silenced all criticism. The new Xenon Design Rationale shows how Xenon is the best data description language. https://xenondata.org/xenon-design-rationale.html https://xenondata.org/xenon-design-rationale.html Comment at https://news.ycombinator.com/item?id=42178359 https://news.ycombinator.com/item?id=42178359
- CableNinja 2y agoIts like you took xml and made a drunken bastardized baby with json. This is ugly and id rather read untabbed json than this hot mess
- trustinmenowpls 2y agoThis 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
- satvikpendem 2y agoYep, I flagged that comment for not being civil, it's simply unnecessary to be so rude.
- akira2501 2y ago> 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.
- trustinmenowpls 2y agoThe point is that he's a stranger and not a close friend, and we're speaking in public. I understand you're trying to say that there's value in honest feedback. But that's generally when it's real feedback that is actionable or at least constructive, this appears to be an attempt at exaggerated humor without anything of value being imparted. You should consider the fact that he's a real human with real feelings and it's simply rude to be disrespectful to talk to anyone this way. 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.
- 2y ago
- the_duke 2y agoThis seems a bit like XML light. Doesn't look enjoyable to read/write.
- GeneThomas 2y agoThere is less typing than JSON.
- Solomoriah 2y agoThere are <> characters, which are awkward on a good day. Yeah, we use them in HTML but the editor helps with that. And there are a bunch of special characters and "objects" that require interpretation. JSON has what? Quotes, square brackets, colons, and commas, used the way they are used in most programming languages, and thus familiar to most of us. Outside of terseness, which is overrated, what real advantages does XENON provide?
- GeneThomas 2y agoSee the opening paragraph.
- milch 2y agoIt seems a bit like a toss-up to me ... Taking examples from your landing page I can see some where there is less typing in JSON and some where there is more. For example, the book one - I counted the equivalent JSON and they were 128 non-whitespace characters vs. 127 non-whitespace characters. Practically, at least for my editor, I had to type less for JSON because every paired character automatically inserts the closing equivalent. This is likely to work across a wide range of editors from the browser console to whatever else fringe text input field. Once you account for paired characters JSON wins at 114 chars. Of course if you had editor support for XENON it could also automatically insert some of the control characters, at the very least all of the > and the <$>, which brings XENON to 117 chars typed. Anyway, I think you probably would've gotten a less strong response from people here if you had less absolute statements on the site ("better alternative", "the best way") - certainly there are going to be use-cases where this excels, but I can also see how the average simple REST API would be very unlikely to benefit from this, and the extra features may in fact expose it to more risk (e.g. the graph support, look at YAML and the CVEs it has caused over the years)
- eviks 2y ago> Xenon is the best way to represent information: terse The best would be to remove all the unneeded unergonomic shift-requiring <characters> from here, you already have = symbol with whitespace and $ that separate all you need <Person> <Name=Fred> <Height=1.67> <$>
- GeneThomas 2y agoThe 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.
- eviks 2y agoSo delineate them when they contain whitespace, for example "quotes serve exactly that purpose". There is no point in delineation when there is nothing to delineate, it's just needless verbosity in a language that aims to be "terse" What exactly is good about <>s that you think it's the good in the bad XML?
- lifthrasiir 2y agoThere is a widespread agreement that XML is generally bad for the data serialization, while HTML is not much questioned as such. You can't carelessly adopt angle brackets without why such difference exists in the first place [1]. [1] Hint: "semi-structured data"
- GeneThomas 2y agoYou mean ʜᴛᴍʟ is not used a such.
- lifthrasiir 2y agoIf you figured that out yourself, you should have also realized that angle brackets are generally considered bad for the data serialization. Cherry-picking my words without answering my whole point is not a good move.
- dongdongzhang 2y agoI prefer JSON as it is really simple
- JKCalhoun 2y agoI prefer JSON as there are libraries for it on every platform and for every language I've needed it.
- cryptonector 2y agoI prefer jq.
- cryptonector 2y agoI should have been clearer. jq is a programming language, but it's also a data language in that a) valid JSON is a valid jq program, b) you can construct JSON data trivially with jq. E.g., : ; jq -n ' .users[0].name="John" | .users[1].name="Jane" ' or : ; jq -n ' .users = [] | .users += [{}|.name = "John"] | .users += [{}|.name = "Jane"] ' but you can make it much much richer than that.
- GeneThomas 2y agoirrelevant
- cryptonector 2y agoThis is not better than XML or JSON. Anything is better than YAML, but this is not great.
- GeneThomas 2y agoMake a point
- cryptonector 2y agoYou're taking this personally. Don't.
- GeneThomas 2y agoSpecific points would be a contribution to the discussion.
- Oras 2y ago> Readable multiple line indented text. Then > <Book> <Name=A Plan> <Author> <Name=Eric Harrison> <Mobile=+64 24 240 990> <$> <<Reviews> Fascinating. <&> Of interest. <&> Worth reading. <<$> <$> Does that look readable to anyone?!
- GeneThomas 2y agoThe “readable indented text” refers to https://xenondata.org/#scalars https://xenondata.org/#scalars where multiple lines of text can be indented and extracted as expected. One can argue that JSON is not readable due to requiring escaping (\n) for multiple line strings.
- Solomoriah 2y agoThis is not enough of an improvement over JSON to justify choosing another format, given that the new format is (A) not recognized and (B) uses even more special characters. (By "not recognized" I actually mean there are no implementations given for any languages, much less accepted standard implementations.)
- GeneThomas 2y agohttps://news.ycombinator.com/item?id=42038004#42038525 https://news.ycombinator.com/item?id=42038004#42038525
- TZubiri 2y agoTo be fair, you omitted the indentations
- GeneThomas 2y agoI believe it is readable, what else could that mean but a Book object with the given name, the author details and an array of three one-line reviews. <Book> <Name=A Plan> <Author> <Name=Eric Harrison> <Mobile=+64 24 240 990> <$> <<Reviews> Fascinating. <&> Of interest. <&> Worth reading. <$>> <$>
- dataspun 2y agoA new better alternative definition of Terse: The act of proclaiming a “new standard” without any user community to speak of.
- GeneThomas 2y agoIt has ALL of the advantages of xᴍʟ.
- dataspun 2y agoWhat advantages does XML have over what? Whatever you’re saying, it’s not as self-evident as you think it is. Respectfully, I think this standard needs to be reframed as version 0.0.1
- Fannon 2y agoThe main advantages of XML (or any standard) is adoption and a wide ecosystem. Unfortunately that beats any "better" standards by a wide margin. 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.
- GeneThomas 2y agoI conject that with programming languages that do not crash schemas used for validation are relatively unimportant. xᴍʟ schemas suffer from the fact that one can not specify that an element may only appear once.
- dataspun 2y agoIn fact, the purpose of the maxOccurs indicator in xsd is to specify that an xml element may only appear once.
- cirwin 2y agoFunnily 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 https://github.com/ConradIrwin/conl value = example map a = b list = 1 = 2 multiline_value = """bash #!/usr/bin/bash echo "hello world"
- lifthrasiir 2y agoAgreed 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 https://github.com/lifthrasiir/cson
- cirwin 2y agoNice – I like your verbatim syntax for multiline strings! 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.
- lifthrasiir 2y agoIndentations are still desired for most human tasks indeed! But you can have indentations and groupings at once, one complementing each other. As you've noticed, CSON's verbatim syntax was intentionally designed so that it remains valid without any indentation but your instinct really wants to align those lines anyway. (A similar approach can be seen in Zig verbatim strings, which seem to be designed independently from CSON and make me much more confident about this choice.)
- GeneThomas 2y agoIndentation in xᴇɴᴏɴ is optional and for readability.
- xyst 2y agoas far as readability goes, I’ll stick with Toml (imo, superior to json, xml). xenon: <<Names> Fredrick <&> Freddy <<$> toml: names = [“Fredrick”, “Freddy”]
- eviks 2y agoNow try to nest your toml and see readability plummet
- recursivedoubts 2y agoI appreciate the work the author has put into this idea.
- Me001 2y agoWhy? Anyone could have done this, these are all fundamentally the same thing anyway.
- recursivedoubts 2y agobecause they care about it and have put some time into it
- chikere232 2y agoThat's very kind, but people doing the wrong thing with passion and energy is functionally worse than them not doing anything
- recursivedoubts 2y agoI view this as harmless at worst and potentially inspirational at best. And the author has learned a lot as well.
- deleted 2y ago[deleted]
- GeneThomas 2y agoHave you? And they are quite different!
- trustinmenowpls 2y agoI know people are hating on it, because who likes a new thing? Especially something that looks kinda like xml. But I personally really liked the structure that xml forced, I just found it to be way to verbose. I find json and yaml and their depedancies on tabs to be confusing and the specs are often abused in ways that make them nearly as hard to parse for a human as xml. This feels like a good middle ground, I hope it receives more support
- GeneThomas 2y agoThanks
- Numerlor 2y agoThe codeblocks don't seem to scale up for me on mobile and are a bit too small to read
- GeneThomas 2y agoOdd
- GeneThomas 2y agoMade them lighter so more legible.
- Numerlor 2y agoBit easier to read not but the code text is still smaller and doesn't fill the phone screen; https://u.numerlor.me/Qzsq https://u.numerlor.me/Qzsq fwiw
- GeneThomas 2y agoAppears to be a bug in your browser. See the embedded css, the <code> block are the same font size just Courier New or a monospace font.
- GeneThomas 2y agoI emboldened the <code> blocks a little. Looks good on Chrome on iPhone but not Edge nor Safari. :o| Thanks.
- hn_throwaway_99 2y agoUnless I'm missing something, a major downside of this is that scale types are not explicit, and that is very, very, very bad IMO. It will lead to numerous cases of poor interoperability as scalars are interpreted differently. That is, in JSON, at least I know "true" represents the string "true", and true represents the boolean value true, and "1.25" is a string and 1.25 is a number. If anything, JSON would be greatly improved by having a specified datetime type, and more guaranteed semantics around numbers (e.g. integers vs. decimals vs floats for example). XML obviously suffers the same issue, and I think it is much worse for not having types (though highlights the difference between structured "documents" vs. object serialization formats).
- GeneThomas 2y agoSee https://news.ycombinator.com/item?id=42038004#42082571 https://news.ycombinator.com/item?id=42038004#42082571 Xᴇɴᴏɴ provides semantics around common data types.
- lifthrasiir 2y agoSorry, 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 example? - There is absolutely no way to indicate the data type. The document accidentally mixes the wire format and serialization protocol; never a good sign. - Do you accept 3,000 or 3,,000 or 30,00 or 3,0,0,0 or ,,,3000 or 3000,,, or 3,e,3 or 0.000,3e7 or ,,,? - How many digits in each group are recommended for the encoder? - What on earth is "IEEE 64 bit double precision floating point numbers" in the context of textual format? - Do you require a specific rounding or not in the decimal-to-binary conversion? - Is `\u{d800}` accepted or not? (JSON famously has this issue.) - If you have to escape the base64 padding, maybe you should just drop the padding? - Graph is generally a bad thing to encode at this level, because many applications do not even expect graphs and that can lead to DoS attacks. - No clear definition of the data model. The document starts with objects, arrays and scalars (untyped? stringy? I dunno), then only reveals that objects can be typed and shared and specific types of scalars should be written in certain ways much later. Define the data model first and describe possible encodings of that model instead. - Not allowing anything besides from space and tab is okay, but that doesn't speed processing to be exact. - While technically a matter of choice, it uses a lot of unmatching angle brackets and that's just... ugly. - In fact, I don't really see why other grouping characters were unused in the first place. - No canonical representation. Maybe you should review tons of other alternatives in this space (I recall at least 2--30 of them, probably much more) before your own design.
- Fannon 2y agoThanks for writing this up! Sounds like you really dig deeply in to this. 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.
- dokyun 2y agoThese aren't S-expressions...
- TZubiri 2y agoIf this is not parody, try to be humbler and not claim to be better than the most popular solutions. 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.
- GeneThomas 2y agoIt IS more terse than ᴊꜱᴏɴ and xᴍʟ and has many compelling features.
- TZubiri 2y agoOk that's good but capitalize TERSE instead of IS. That way you acknowledge that terseness is one of many parameters of a string data structure instead of focusing on our disbelief of its terseness.
- GeneThomas 2y agoA basic scalar pair in ᴊꜱᴏɴ is "key":"value", or "key":value, so a 4 or 6 character overhead. xᴇɴᴏɴ is <key=value>, 3 characters. In my tests xᴇɴᴏɴ IS more terse.
- TZubiri 2y agoBut no one said it wasn't. And also no one particularly cares, you can have your crown for king of terseness, the criticism isn't that. You are being criticized for quality and your response is to fixate on one parameter being better. It's as if you were overweighing that parameter or ignoring the other million of parameters, which is what makes your proposal so out of place. Suppose that you come to the world economic forum, and you propose a new coin you call the GeneThomas coin. When people criticize or laugh about your idea, you respond that "The coin IS greener! It really is and I can prove it". Man, you are just showing that you don't understand anything about what makes a currency good or popular. Just find your niche in green coins, but don't try to compete with the US dollar or bitcoin cause you'll lose
- druchan89 2y agoi dont understand how it's "terse"? like, terse compared to XML alone?
- GeneThomas 2y agoSee https://news.ycombinator.com/item?id=42049033 https://news.ycombinator.com/item?id=42049033 As terse as ᴊꜱᴏɴ.
- zzo38computer 2y agoI have read this document, and I don't really like this alternative, much. However, one consideration should be that one format is not necessarily suitable for everything; there will be differences by data model and other stuff. Different formats have different advantages and disadvantages, both in general and for specific applications. I had recently been working on something too, called TER. It is a pure ASCII file (although some implementations might support other character sets, mine doesn't, although non-ASCII characters can still be represented using escape sequences). It can be converted to DER (a program can also be written to convert the other direction (BER to TER), but this is not done yet). It is ASN.1X which is a variant of ASN.1; a few types are removed (OID-IRI, and a few others) and some new types are added (BCD string, TRON string, PC string, key/value list, OBJECT IDENTIFIER RELATIVE TO, and a few others), and also a few types are deprecated (such as UTCTime), although they are intended to not conflict so that it is possible to implement both in the same program if you want to do. (ASN.1X also removes or restricts some other features of ASN.1, such as that optional fields and fields with a default value are not allowed if it would require to look ahead to determine the absence or presence of the field.) Xenon has a type for references to other nodes. I had considered (before seeing the document about Xenon) adding such a type into ASN.1X, although I had not done so yet. (My idea is to use a relative format (I have the idea how this will be encoded in DER, although I am not sure about TER; for TER it might require multiple passes, and currently the implementation uses only a single pass), that if some structure is taken out and moved to another file, and it only references within that structure, the reference will remain intact, and it cannot interfere.) TER also uses the same comment syntax than Xenon (although, so does PostScript, and probably others too). Perhaps another thing to be noted is PostScript notation; a subset of the PostScript notation could be used for arrays and key/value lists and some such things like that (and is something I sometimes use).
- GeneThomas 2y agoTER is irrelevant. The Internet has shown the advantages of text formats at the high level, e.g. email and the web.
- happytoexplain 2y agoI would feel much more kindly toward this if it didn't start out by claiming to be better than JSON.
- GeneThomas 2y agoMake a point
- rohithgilla 2y agoApple tried something similar https://pkl-lang.org/ https://pkl-lang.org/
- lifthrasiir 2y agoPkl belongs to a related but different category of "configuration" languages, while we are talking about a pure serialization format. A serialization format can be used as a configuration language if designed carefully, but they are distinct.
- GeneThomas 2y agoXᴇɴᴏɴ excels at both.
- lifthrasiir 2y agoPlease refrain from replying the same thing over and over, especially to obviously sidetracked comments.
- GeneThomas 2y agoThat is the only place that I have stated xᴇɴᴏɴ’s applicability to configuration and data.
- racingmars 2y ago"Documents must be utf-8 and should have a byte order mark." No. If you're using UTF-8 (which is a good choice), the use of a BOM should be discouraged. Given that the format specification says documents MUST be UTF-8, there is no need to enable detection of UTF-8 content with the UTF-8 BOM. And, of course, the original purpose of the BOM (detecting big- or little-endian encoding) is unnecessary in UTF-8. The Unicode standard, section 2.6, says, "Use of a BOM is neither required nor recommended for UTF-8". While it is allowed, if you're making a new spec for a new data format, you shouldn't recommend the use of a BOM in UTF-8.
- GeneThomas 2y agoThere exists a charset that is more efficient than UTF-8.
- GeneThomas 2y agoI am futureproofing.
- lifthrasiir 2y ago> There exists a charset that is more efficient than UTF-8. > I am futureproofing. Which is true: such charset does exist today, or you merely have prepared for that in the future?
- GeneThomas 2y agoThe charset is not published, when it does eventuate byte order marks safeguard the interpretation of documents.
- slater 2y agoWhich is…?
- GeneThomas 2y ago
- tripple6 2y agoSorry but I would never use this format for both manual or programmatic approach. * I've tried to read the data this format describes without reading its documentation and I just failed: the format is amazingly counter-intuitive. I never had a readability and understanding issues with XML/HTML, JSON or even YAML (that I think is overly complicated) when I saw them for the first time. * Terse does not mean cryptic. Basic notation is just weird: why would it need unbalanced the less-than symbol to open the array? Why `<&>` for delimiting elements? Why `<<$>` but not `<$>>` at least just to be more readable by human and look balanced? The syntax goes more weird for arrays containing objects: indents (okay to some extent), `<>` and `<&>` (`{` and `}`?). * Auto-removing whitespaces may hurt. If the format offers this, would it also offer a heredoc-style text like `cat <<EOF` in Bash so that the formatting could be preserved as is? `xml:space` and JSON string literals were designed exactly for this. (upd: I just saw new symbol: `|`... Well, okay, but another special character now.) * Native support for arrays. I mentioned a few above. `<<Faults$$>` and `<<$$>` -- guess what these two mean if you see this first time? You would never guess. It's an empty array and an empty element, you've just failed. * Graphs... Another weird syntax comes into the room: `#id;` but `@id` (no semicolon?). Okay, these seem to be first-class ids and refs, not necessarily designed for graphs (I'm not sure if the `#ID;` and `@` would play perfect with any non-empty names.) But what does graphs make first-class citizens here and why? Graphs can be expressed, I believe, in any data/markup format/language and then processed with a particular application if graphs are needed. By the way, arrays and objects are not necessarily trees from the semantic point of view. More graph processing issues were mentioned in other comments to this topic. What about the first-class support for sets? I'm kidding * Comments. Another symbol here to come: `%`. To be honest, I can't recall any instance I could see the percent sign elsewhere for this purpose. What if the comments would start with a well-known `#` at least with a space right after it so that it wouldn't be considered a "graph id" (or, don't get me wrong, with another `<`/`$` sequence) * Just got to the Escaping section and now I see how the characters are escaped. Perhaps this is okay. * Scalars. Crazy number formatting and locale issues are waiting. The never-on-keyboard infinity symbol would be great for APL, but why not just Inf(inity)? Whatever the scalar value is, no need to cover all existing primitive scalars -- just let them be processed by an application since all scalars are text semantically. Another crazy things: what does make UUIDs that special for this format?; why does make Base64 that special so that it has native support (would it support Base16 for human-readable message digests; or Base58 to remove visually lookalike Base64 characters)? * CR/LF? I can understand its semantic purpose, but why not LF to make it even more "blazingly" fast? Say good-bye to UNIX users. * The cognitive load for the markup syntax absolutely does not make it efficient in typing. Believe me, it does not. What I would do, I would probably enhance the widely used formats, say make JSON, which I find almost perfect from the syntax point of view, not require quotes for object property names if the names would not contain special characters like `:` just like it goes in JavaScript. And perhaps make XML "v2" move away from SGML hence loosening its syntax to get rid of the closing tags with shorter notation, first-class array support and fixing syntax issues especially for CDATA and comments that can't support `--`. You would blame me, but I love XML the most: it just has the richest set of standardized amazing well-designed extensions to operate XML with regardless the heavy XML syntax. P.S. How does it look like in the document it marks up is minified (e.g., no whitespaces)?
- cvjcvjcvj 2y agoWe could do all this in Lisp more than 60 years ago, sorry.
- GeneThomas 2y agoNo; I don’t believe so.
- cirrus3 2y agoI dislike this very much.
- GeneThomas 2y agoGood.
- GeneThomas 2y agoMake a point.
- Hizonner 2y agoStop. Just stop this madness. Nobody needs any new formats. We had s-expressions. They were OK. We had ASN.1. It was OK. We had .ini files. They were OK-ish. We had XML. It was OK. We had JSON. It was OK. We had YAML. It was OK. We had TOML. It was OK. We had probably a million other fundamentally isomorphic solutions to this basically trivial problem, and each of them was more or less OK. What is not OK is endless proliferation because somebody has some trivial gripe and wants to make a name for themselves.