RejectedSoftware Forums

Sign up

Pages: 1 2

Re: Are you sure about SDL?

On 8/25/2014 5:09 PM, Jonathan Marler wrote:

Yes you are correct! ASON's semantics are dependent on the application. That's where the name "Application Specific" came from. The following features make the text "Application Specific"

  1. optional colons/commas
  2. omitting root level braces or brackets
  3. Nameless object fields.

I've noticed that in most applications it's unnecessary to specify the structure of the data you are representing because the application already knows what kind of data it is expecting. This concept is what makes ASON unique from other JSON variants. This is the main concept I wanted to get people's opinions on. There are advantages and disadvantages to it. Thanks for taking the time to read it and understand what makes it unique.

Hmm, yea, at the very least, it's definitely an interesting idea.

But I'm unconvinced that it brings enough benefit that can't be achieved
in other way (such as schemas) to be worth the downsides (such as
inability to do generalized ASON processing, and being so different from
what people are likely to expect). In any case, I think the approach,
while certainly worth exploring, is too much of an experimental idea for
dub, at least for now.

But I'm not opposed to the idea of a JSON superset that makes things
easier for human reading/writing. I think the world needs that. And as
much as I do like SDL, I agree it has things I might've done differently.

YAML is another language that attempts to be a nicer JSON superset, but
I find it goes overboard with various ideas and syntaxes and winds up
being confusing and complex. Also, it's already been discussed as a
potential dub language before, and very few people preferred it over
SDL. Only one person, IIRC, maybe two.

I feel like what's needed in a JSON-superset is a greatly-simplified
approach compared to YAML and ASON: It should have a fundamental,
deliberate design principle of avoiding feature-creep and keeping it
absolutely as simple as possible. After all, simplicity is the whole
point of JSON and a key reason for its popularity.

So aside from adding some strong-types (which, I agree with the SDL
creator, are very important), a syntax or feature would only be added
in this "JSON Plus" language if absolutely necessary to achieve the
main goal of "JSON, but without being so syntax-noisy, so it's easier
for humans to read/write". Again, we don't want to damage JSON's key
benefit of ultra simplicity - just relax it slightly, just enough to
bring some pragmatism.

The goal would not be to remove as much punctuation as possible.
That's a common trap I think many modern languages keep falling into, to
various undesirable consequences. Rather, the goal is to bring just
enough
pragmatism to JSON as necessary, without beginning to erode its
key benefits.

I'm thinking something like this (you'll notice this does have some
similarities with your ASON, but more simplified and more rigid):

  • Start with JSON.

  • Permit the outer {} to be omitted. Not on all objects, JUST on the
    root object. It's completely unnecessary noise on that one.

  • Permit trailing commas.

  • Permit strings to be written as unquoted identifiers instead of string
    literals (Except of course for keys that contain spaces or anything
    non-identifier like that).

  • Maybe permit commas to be omitted inside of arrays.

  • Not so sure about allowing commas to be omitted outside arrays.
    Probably NOT, optional commas outside of arrays seems like it could be a
    recipe for problems, especially when combined with unquoted stings: You
    forget the quotes on just one "I have spaces", and entire chunks of
    the file could silently get parsed incorrectly. Syntax errors are
    good. Much better than silent errors and subtle bugs. And I don't
    think keeping those commas would be real syntactical noise: Allowing
    unquoted strings is already enough to cut JSON's syntax down to a vastly
    more manageable level.

  • Maybe allow newlines to be implicit commas. The language would still
    effectively be pretty much freeform. But careful consideration of the
    exact rules of this would be needed to avoid a JavaScript-like mess. It
    would NEED to be very simple in BOTH its rules AND all its implications.
    The moment corner cases appear, the whole idea must be nixed.

  • Add SDL's types. I agree with the SDL creator that stong-typed data is
    important. But unlike SDL, the strong numeric types would require use
    of the suffixes, otherwise you just get JSON's traditional generic
    number type (necessary for the sake of backwards-compatibility with
    JSON). Also, the base64-binary notation would probably need adjusted to
    avoid conflicting with JSON arrays.

  • Simplify and formalize the date/time grammar (compared to SDL). That's
    the biggest thing I'd change about SDL if I could. It's way
    overly-permissive, lax, poorly-defined. I got the impression it was
    defined entirely as "Whatever Java's standard string-to-date/time
    functions just happen to accept".

  • (Probably the hardest part of the job) Define a standard format for
    schema definitions (that naturally uses the language itself). A D
    library could also be created that automatically generates schemas based
    on UDA-annotated structs.

  • As part of the schema definition format, include the ability to define
    enum-like "set" types: Types that are restricted to a pre-defined set of
    values. The end-user would just use these like any other
    string/numeric/etc type, but the schema validation would enforce that
    the value matches one of the pre-determined options.

  • JSON's true/false and null would be demoted from keywords to special
    built-in "predefined set" types.

  • Nameless fields would NOT be necessary, nor supported. Instead, JSON's
    arrays can already be used to accomplish the same thing. If you want
    your data format to support "either named fields or nameless values in
    an array - your choice!" then you can define your schema to accept
    either possibility.

Re: Are you sure about SDL?

For the record, I would prefer YAML or TOML of all formats...

Format used by DUB should be something made for humans. No matter how I like
or dislike JSON, it is not made for humans. - It is made to be easy to
parse. YAML and TOML (https://github.com/toml-lang/toml) were made for
humans and IMHO they should be used for these purposes.

http://dejan.lekic.org

Re: Are you sure about SDL?

On Thu, 28 Aug 2014 19:54:13 +0100, Dejan Lekic wrote:

For the record, I would prefer YAML or TOML of all formats...

I have to agree that TOML looks like a better choice now.
SDL isn't used anywhere http://sdl.ikayzo.org/display/SDL/Projects+Using+SDL.
And the fact that it's a tag+attribute format like XML make it much harder to map to JSON, e.g. we'd need separate documentation and it's 2 very different formats to learn.

TOML on the other hand maps directly to JSON. Meaning we don't need a new internal data type and can share the documentation.
Also it has a lot more momentum.
https://github.com/toml-lang/toml#projects-using-toml

Simple decision IMO.

Now we just need to get the parser in shape and we're done before next week.
https://github.com/iccodegr/toml.d

Pages: 1 2