4 ms·

> 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

> 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 "<person><Height=1.67><$>". 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.

GeneThomas 2y ago
> * 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. << means it relates to starting an array, $>> means it is the end, $$ meaning something else — an empty array! The xᴍʟ alternative is a bodge: public class PurchaseOrder { public Item[] ItemsOrders; } public class Item { public string ItemID; public decimal ItemPrice; } serializes to: <PurchaseOrder> <ItemsOrders> <Item> <ItemID>aaa111</ItemID> <ItemPrice>34.22</ItemPrice> </Item> <Item> <ItemID>bbb222</ItemID> <ItemPrice>2.89</ItemPrice> </Item> </ItemsOrders> </PurchaseOrder> Where the array is marked up as two sub elements both called <Item>: Xᴇɴᴏɴ has first class support for arrays: <PurchaseOrder> <<ItemsOrders> <ItemID=aaa111> <ItemPrice=34.22> <&> <ItemID=bbb222> <ItemPrice=2.89> <$>> <$> The elements may be scalars so <PurchaseOrder> <<ItemsOrders> <$>> <$> has an array with one item of the empty string. So a separate syntax for empty arrays is required! <PurchaseOrder> <<ItemsOrders$$>> <$>

GeneThomas 2y ago

> * 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. << means it relates to starting an array, $>> means it is the end, $$ meaning something else — an empty array! The xᴍʟ alternative is a bodge: public class PurchaseOrder { public Item[] ItemsOrders; } public class Item { public string ItemID; public decimal ItemPrice; } serializes to: <PurchaseOrder> <ItemsOrders> <Item> <ItemID>aaa111</ItemID> <ItemPrice>34.22</ItemPrice> </Item> <Item> <ItemID>bbb222</ItemID> <ItemPrice>2.89</ItemPrice> </Item> </ItemsOrders> </PurchaseOrder> Where the array is marked up as two sub elements both called <Item>: Xᴇɴᴏɴ has first class support for arrays: <PurchaseOrder> <<ItemsOrders> <ItemID=aaa111> <ItemPrice=34.22> <&> <ItemID=bbb222> <ItemPrice=2.89> <$>> <$> The elements may be scalars so <PurchaseOrder> <<ItemsOrders> <$>> <$> has an array with one item of the empty string. So a separate syntax for empty arrays is required! <PurchaseOrder> <<ItemsOrders$$>> <$>