The advent of SDA

 A long time ago, somewhere in the year 2008, I had this conviction that XML was over-complicated and too bloated for the purpose of simple data transfer or application integration, and that there ought to be a simpler alternative.

At that time, JSON was not as widespread as it is nowadays, and I entirely overlooked it. So rather than seeing this as the obvious alternative and go about my day, I designed my own "language".

After completing the specification, I realized I reinvented the wheel, but by that time it was already too late and SDA had been conceived. Not being content with a specification alone, I then set out to write a parser to process SDA content.

Incidentally, SDA is short for Structured (or Simple) DAta, and it looks like this:

addressbook {
    contact {
firstname "Alice"
phonenumber "06-11111111"
phonenumber "06-22222222"
    }
    contact {
firstname "Bob"
phonenumber "06-33333333"
phonenumber "06-44444444"
    }
}

This might represent your contacts in a format suitable to some hypothetical application, and it would be trivial to extend this with addresses and all kinds of other information. The SDA format doesn't get more complicated than this, so I am sure you get the idea.

My inner programmer especially likes the curly braces. It is certainly easier to read than XML, and less bloated when compared to  

<addressbook>

    <contact>

<firstname>Alice</firstname>

<phonenumber>06-11111111</phonenumber>

<phonenumber>06-22222222</phonenumber> 

    </contact>

    <contact>

<firstname>Bob</firstname>

<phonenumber>06-33333333</phonenumber>

<phonenumber>06-44444444</phonenumber> 

    </contact>

</addressbook>

In fact, I think it looks better than JSON, too:

{

  "addressbook": {

    "contact": [

      {

        "firstname": "Alice",

        "phonenumber": [

          "06-11111111",

          "06-22222222"

        ]

      },

      {

        "firstname": "Bob",

        "phonenumber": [

          "06-33333333",

          "06-44444444"

        ]

      }

    ]

  }

}

Thumbs up for the braces. The array notation is nifty, though in large and/or nested arrays it is hard to keep track of what you are looking at, without the object names. And what's with all those punctuation marks?

So there you have it, SDA. I expect nothing short of world domination somewhere around the year 2032.

But seriously, at that time it didn't feel like SDA was going to make a difference anywhere, and it still does not. It might have been somewhat useful for human-readable configuration files but nowadays YAML seems to be more than appropriate for that. So what I was left with was a pet project and an exercise in writing a parser.

I more or less forgot about the whole thing until 2020, when I came across the Java sources in a back-up. And before I knew it, I found myself designing a schema language to describe SDA content, which I called SDS - Simple Data Schema. 

Which looks like this:

schema {
    node {
        name "addressbook"
        node {
            name "contact" occurs "0..*"
            node { name "firstname" type "string" }
            node { name "phonenumber" type "string" occurs "1..*" }

        }
    }
}

This formally describes our hypothetical address book, and as you can see, SDS itself is written in SDA, very much like XSD is written in XML and JSON schema in JSON. 

If you think I was taking this thing way too serious, you are probably right. But this was during the COVID-19 pandemic, and I really needed to do something.

Once the SDS specification was complete I wrote a parser for it, as well as a validator to check the syntactical correctness of SDA data against a corresponding SDS.

Is all this useful to you? Probably not.

But it's out there.

https://github.com/hclbaur/sda-core

https://github.com/hclbaur/sds-core