Alternatives to XML?

[Roland Koebler]

Hi,

after reading the mails of this thread, I would recommend one of the
following ways:

1. Use a computer-readable format and some small editor for humans.
   
   The file-format could then be very simple -- I would recommend JSON.
   Or some kind of database (e.g. SQLite).

   For humans, you would have to write a (small/nice) graphical editor,
   where they can build the logic e.g. by clicking on buttons.
   This can also work for non-programmers, since the graphical editor
   can be adapted to the indended users, give help, run wizards etc.

or:

2. Use a human-readable format and a parser for the computer.

   Then, the fileformat should be optimized for human readability.
   I would recommend a restricted subset of Python. This is much more
   readable/writeable for humans than any XML/JSON/YAML.
   And you could even add a graphical editor to further support
   non-programming-users.

   The computer would then need a special parser. But by using
   Python-expressions (only eval, no exec) and a parser for flow
   control (if/else/for/...) and assignments, this is not too much
   work and is good for many applications.

   I've written such a parser incl. some kind of (pseudo-)sandbox [2]
   for my template-engine "pyratemp" [1], and I've also used it for
   small user-created-procedures.

   [1] http://www.simple-is-better.org/template/pyratemp.html
   [2] It's not a real sandbox -- it's secured only by restricting
       the available commands. If you add unsafe commands to the
       pseudo-sandbox (e.g. Pythons "open"), the user can do bad
       things.
       But without manually adding unsafe commands, I don't know
       any way to get out of this pseudo-sandbox.
       And if you really need a sandbox which is more powerful
       than my pseudo-sandbox, you may want to have a look at
       the sandbox of PyPy.


Trying to use a format which is both directly computer-readable
(without a special parser) and well human readable never really
works well in my experience. Then, you usually have to manually
read/write/edit some kind of parse-tree, which is usually much
harder to read/write than code. But if you want to do this, I
recommend LISP ;).

(By the way: If I did understand your mails correctly, your
program would probably break if someone edits the XML-files
manually, since you're using some kind of XML-like-fileformat
with many non-intuitive assumptions.)


Roland


PS: 

On Wed, Aug 24, 2016 at 04:58:54PM +0200, Frank Millman wrote:
> Here is a JSON version -
> 
> {
>  "case": {
>    "compare": {
>      "-src": "_param.auto_party_id",
>      "-op": "is_not",
>      "-tgt": "$None",
>      "case": {
>        "on_insert": {
>          "auto_gen": { "-args": "_param.auto_party_id" }
>        },
>        "not_exists": {
>          "literal": { "-value": "<new>" }
>        }
>      }
>    }
>  }
> }
I think this is not really good. In JSON, you also have lists, and in this
case, it would probably be better to use some lists instead of dicts, e.g.:

[
    ["if", ["_param.auto_party_id", "is not", "None"],
	["if",   ["on_insert"],  ["set", "value", ["call", "auto_gen", "_param.auto_party_id"]]],
	["elif", ["not_exists"], ["set", "value", "'<new>'"]]
    ]
]

I think this is much more readable than your XML-code and the
auto-converted JSON.

And it's even less ambigious. (How do you distinguish between the
variable _param.auto_party_id and the string "_param.auto_party_id"
in your XML-example?)