Alternatives to XML?
Roland Koebler
rk-list at simple-is-better.org
Fri Aug 26 15:27:39 EDT 2016
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?)
More information about the Python-list
mailing list