GeneThomas

I 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

Comment at https://news.ycombinator.com/item?id=42178359

I 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

Comment at https://news.ycombinator.com/item?id=42178359

Thanks

They are for less than and greater than in mathematics!? They are good in markup for a number of reasons including that they stand out.

I 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.
      <$>>
  <$>

See https://news.ycombinator.com/item?id=42038004#42083249

> * 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$$>>
  <$>

I emboldened the <code> blocks a little. Looks good on Chrome on iPhone but not Edge nor Safari. :o|

Thanks.

> I guess Xenon is designed to be not comfortable for the vast majority of people including me then?

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.

The point is one can apply the xᴇɴᴏɴ library to arbitrary data and generate representative markup. For “Egyptian hieroglyphs not encoded in Unicode” 𓀠 one can write plug-ins.

There is the concept of “well formed xᴇɴᴏɴ” as outputted by the ᴅᴏᴍ and serializer which is deterministic as will suffice for canonicalization.

Specific points would be a contribution to the discussion.

The charset is not published, when it does eventuate byte order marks safeguard the interpretation of documents.

See https://news.ycombinator.com/item?id=42038004#42082571

Xᴇɴᴏɴ provides semantics around common data types.

> angle brackets are generally considered bad for the data serialization.

Not a point.

Thanks

That is the only place that I have stated xᴇɴᴏɴ’s applicability to configuration and data.

Appears 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.

> 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.

Have you?

And they are quite different!

Made them lighter so more legible.

No; I don’t believe so.

Make a point.

Odd

I 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.

Make a point

Xᴇɴᴏɴ excels at both.

irrelevant

You mean ʜᴛᴍʟ is not used a such.