04.25.2009

Sick and tired of XML as a human interface?
You came to the right place!
Swush is a simple markup language ideal for configuration files and structured data that should be manipulated by both people and computers.
Here is an example of a swush configuration file:

Check the what is swush page for more information.
There is already a working Java implementation available at the download page.

Comments

  1. ehhh on 04.25.2009

    is it just like JSON?

  2. admin on 04.26.2009

    No,
    JSON is designed to be easily parsed by JavaScript, not by people.
    you have redundant quotes and commas in JSON.

  3. Jos Hirth on 04.26.2009

    Looks similar to CurlyML. However, unlike curly it got a usable license (BSD instead of GPL).

    Thanks for sharing, Omry. 🙂

  4. admin on 04.26.2009

    You’re welcome 🙂
    Yup, is is somewhat similar, I wasn’t aware of it.
    one difference is that in Swush the basic type is a key:value pair, and not w word.
    I think this makes it simpler for most uses.

  5. zproxy on 04.26.2009

    looks like YAML to me

  6. Omry on 04.26.2009

    It’s similar, but I didn’t like the syntax of yaml.
    there are several differences, one being that scope in swush is not determined by block indentation (like in yaml)

  7. Jacques Lemire on 04.26.2009

    Remark 1
    how do you code/encode long strings, like a long paragraph, with quotes, doubles, and curls

    Remark 2.
    I find it simple, direct and powerful to be able to write “bare” strings like format : %t%s
    BUT the problem is with languages like C# or even Python where the new formats are like {0:3d}={1:6d}
    Notice the colon in the format.

  8. Omry on 04.26.2009

    Hi Jacques,
    Good questions.
    1. You use double quotes for complex strings, like:

    “this is a very long
    sentence : it have a few
    new lines, some {curly} braces and even some \”quotes\”!”

    note that you need to escape the quotes inside the string by prefixing with a backslash.
    in the current version, the returned string will contain the \” instead of “, but I`ll fix it soon.

    2. since you can use quotes as I explained, I am not sure it’s a real problem.
    if you disagree please explain.

  9. artm on 04.27.2009

    escaping quotes with slashes is ugly. starting long string on the (key : “… ) line breaks indenting that might be present in the quoted multi-line string. may be better allow something like:

    key : DELIM
    string
    string
    “quoted string”
    DELIM

    where DELIM is something rare, like “”” (triple quote) or ~~ ? (in the above example the long string doesn’t start / end with empty lines, it only contains lines between the two lines containing DELIM, each content line is \n terminated for consistency)

  10. Omry on 04.27.2009

    We discussed something like this last night.
    need to think about it, how it interact with normal quoted strings.
    you still want:

    key : “a value”

  11. artm on 04.27.2009

    I’m not so sure about “a value”. the language is line based, keys can’t contain spaces, anything after colon is a value barring leading / trailing white space.

    even braces inside a single line value shouldn’t be a problem: if brace (or even colon) is after a colon it’s part of the value, making the following parseable:

    url : http://swush.firefang.net/
    title : swush ain’t afraid of no {}

    only when brace immediately (bar white space) follows a key does it start a new group. this rule can be extended to allow a different formatting:

    grp
    {
    key : value
    }

    the key to lexer / parser programming will be using states – are we parsing a key, delimiter or value now (or something).

    you’ll obviously need string-delimiters for multi-line strings (well, not obviously, you could also escape new lines, but that’s again ugly), but I’m not sure you need quotes for single line strings. May be to escape comment delimiters.

  12. Omry on 04.27.2009

    swush is not line based, you can have this:
    swush {key:value key:value}

    or, in the next version:
    array [1 2 3]

    with your suggestion, the first one will be parsed as:
    KEY: key
    VALUE: value key:value

    currently line breaks are treated as separators and are ignored.
    I think that’s the formating flexibility offered by this approach outweigh the benefits of never having to quote a string.

    about multiline strings, as I said – your suggestion is good and I`ll see if it can cleanly merged into the swush (but as an addition, not instead of anything else).

  13. artm on 04.27.2009

    and I would suggest another addition to the language:

    grp {
    key : value
    }

    is equivalent to

    grp.key : value

    from the API i would like to be able to access the values like: cfg[“grp”][“key”] or better cfg[“grp.key”], or, say in python, as cfg.grp.key which somehow makes me want to enforce the dot notation 🙂

  14. artm on 04.27.2009

    ah, i see, newline is just like any white space. i can see the value of that in case of arrays.

  15. Omry on 04.27.2009

    that’s an api issue:
    how do you access elements in a swush file programatically.

    that’s a different issue, an in fact I think it’s justifies having a selector language.
    I already implemented the dot notation to access elements (check the Swush.select() or the bottom of the “What is swush” page.
    I think we should look at xpath for inspiration for more ideas for the selector language, but first we need to stabilize swush itself.

    btw: get online on jabber, I can’t see you.

FireStats icon Powered by FireStats