Earlier quoted context omitted.
Odd
Made them lighter so more legible.
Bit easier to read not but the code text is still smaller and doesn't fill the phone screen; https://u.numerlor.me/Qzsq fwiw
New better alterative to XML, JSON and YAML
131–140 of 148 posts
Re: New better alterative to XML, JSON and YAML
#132Earlier quoted context omitted.
> Again, how is this different from `xml:id` It is a tidier solution. > I still can't get what makes timestamps (and GUIDs) so special so that they have special sections in your document. They are common in data. > [...] boolean attributes Separate attributes and sub elements is a mistake. One should be able to guess an ᴀᴘɪ. > What more scalar types it can be extended with? > letting the application make decision how…
> It is a tidier solution. Based on special syntax. You're about to introduce node attributes. > They are common in data. I use tables everyday. May I have "first-class graph support" but for tabular data that is very common as well? I expected three or four times you eventually explain what makes the graph support and how it differs from declaring ids and refs in other formats you think are worse than yours. No answ…
> You're about to introduce node attributes.
Yes, but limited to #id and :type.
> tabular data that is very common as well?
Xᴇɴᴏɴ has first class arrays also so tabular data could be stored as such.
> explain what makes the graph support and how it differs from declaring ids and refs in other formats you think are worse than yours. No answer.
It is built in!
> So why would it care the formatting at all?
FOR INTEROPERABILITY! That is different implementations of xᴇɴᴏɴ agree on what a ɢᴜɪᴅ or date looks like! Fʏɪ, with a good implementation of xᴇɴᴏɴ you just point the library at your data, sometimes augmented with some attributes, and you get cleanly formatted markup.
>>One should be able to guess an ᴀᴘɪ.
> For the second, API for what?
Say you are using an ᴀᴘɪ for information about a person and their is information about their height, in xᴇɴᴏɴ one knows there shall be a scalar called “Height”, in xᴍʟ it may be an attribute or a sub element.
>> Yes. Human have to read markup.
> Format should not care too much.
We are using text formats because they are READable to humans.
> Separate digits with underscores or spaces.
That is not standard anywhere.
> [...] color highlighting
Only the application knows if a scalar is a number or a string.
There are no obvious design flaws. Take xᴍʟ, add an array type and xᴇɴᴏɴ results.
We must be talking a cross purposes re formatting. [phew...] An application has an object called Person, and a field called Height with a type of double. C♯: Person fred = new Person { Height = 1.67 }; string xenon = XenonStart.Serialize("person", fred), results in the string "". A xᴇɴᴏɴ implementation in another language, say JavaScript can take that xᴇɴᴏɴ string and decode it into an object with a field called Height with a value that can be decoded .AsNumber into 1.67; because there is a standard for encoding a ɪᴇᴇᴇ 64 bit number/.net double/JavaScript number.
Xᴇɴᴏɴ has more benefits.
Re: New better alterative to XML, JSON and YAML
#133Earlier quoted context omitted.
Made them lighter so more legible.
Bit easier to read not but the code text is still smaller and doesn't fill the phone screen; https://u.numerlor.me/Qzsq fwiw
Appears to be a bug in your browser. See the embedded css, the
block are the same font size just Courier New or a monospace font.Re: New better alterative to XML, JSON and YAML
#134Re: New better alterative to XML, JSON and YAML
#135I 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…
Thanks
Re: New better alterative to XML, JSON and YAML
#136Earlier quoted context omitted.
You mean ʜᴛᴍʟ is not used a such.
If 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.
> angle brackets are generally considered bad for the data serialization.
Not a point.
Re: New better alterative to XML, JSON and YAML
#137Unless 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 greatl…
See https://news.ycombinator.com/item?id=42038004#42082571
Xᴇɴᴏɴ provides semantics around common data types.
Re: New better alterative to XML, JSON and YAML
#138Earlier quoted context omitted.
I am futureproofing.
> 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?
The charset is not published, when it does eventuate byte order marks safeguard the interpretation of documents.
Re: New better alterative to XML, JSON and YAML
#139Re: New better alterative to XML, JSON and YAML
#140Earlier quoted context omitted.
Is canonilization not irrelevant. Any format with comments is not canonical; so xᴍʟ is not, ᴊꜱᴏɴ has escapes options for string characters so it not either. Response to graph conjecture stated https://news.ycombinator.com/item?id=42072133 .
Almost no serialization format is canonical by default---AFAIK bencode was the sole example that mandates the canonicalization. Instead, a canonical subset of the format is usually defined, which would of course exclude comments, unless comments themselves are considered semantic like XML. Yes, even XML has a canonical subset [1]! [1] https://www.w3.org/TR/xml-c14n/
There is the concept of “well formed xᴇɴᴏɴ” as outputted by the ᴅᴏᴍ and serializer which is deterministic as will suffice for canonicalization.