I have silenced all criticism.
The new Xenon Design Rationale shows how Xenon is the best data description language.
10 karma · joined December 25, 2022
The new Xenon Design Rationale shows how Xenon is the best data description language.
The new Xenon Design Rationale shows how Xenon is the best data description language.
The linked document justifies all design decisions.
Please try to make valid criticism.
<Book>
<Name=A Plan>
<Author>
<Name=Eric Harrison>
<Mobile=+64 24 240 990>
<$>
<<Reviews>
Fascinating.
<&>
Of interest.
<&>
Worth reading.
<$>>
<$><< 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;
}
<PurchaseOrder>
<ItemsOrders>
<Item>
<ItemID>aaa111</ItemID>
<ItemPrice>34.22</ItemPrice>
</Item>
<Item>
<ItemID>bbb222</ItemID>
<ItemPrice>2.89</ItemPrice>
</Item>
</ItemsOrders>
</PurchaseOrder>
Xᴇɴᴏɴ has first class support for arrays:
<PurchaseOrder>
<<ItemsOrders>
<ItemID=aaa111>
<ItemPrice=34.22>
<&>
<ItemID=bbb222>
<ItemPrice=2.89>
<$>>
<$>
<PurchaseOrder>
<<ItemsOrders>
<$>>
<$>
<PurchaseOrder>
<<ItemsOrders$$>>
<$>Thanks.
You seem fairly comfortable with the rest of English. Korean numbers do not seem to scale well.
> allow `$` or not requires a single example
Java allows $ in identifiers.
Xᴇɴᴏɴ provides semantics around common data types.
Not a point.
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.
And they are quite different!