Am 03.12.2013 12:10, schrieb Dejan Lekic:

On Tue, 03 Dec 2013 11:44:43 +0100, Sönke Ludwig wrote:

Am 03.12.2013 10:43, schrieb Dejan Lekic:

As much as I dislike XML, I think it is not a good idea to ignore it. XML should definitely be among the supported formats. Also, it would be nice to have a converter between them in the case package owners decide to switch to an alternative.

I don't know, the purpose of the alternative format discussed here is
supposed to improve human readability (which XML surely doesn't offer).
But on top of that I really think it would be a bad idea to complicate
the system with more formats without a very good reason. JSON should be
universal enough as the standard format for machine data exchange. What
would XML really offer additionally in practice?

Having said that, SDL is structurally more or less the same as XML, so a
generic XML<->SDL converter could be used for this.

I would agree with to a certain degree. But the moment your project becomes complicated, no format will make it readable. You will struggle with any format, especially when you autogenerate (and that is going to happen) DUB JSON. And the more it is close to be machine readable than human readable the higher is the need of a tool that can aid person in altering something. There are thousands of XML tools out there, as you already know. Plus, it is a standard exchange format in many environments. I've seen literally unreadable JSON in many places, and I am 100% sure you have seen it too. DUB JSON files will probably continue being human readable because humands made them, and edit them. :)

It may sound naive, but I truly hope that the package description files
will stay manageable due to proper modularization and with the help of
proper format/DUB features. The "sub package" feature, which I don't
really like, doesn't really help there, but as long as things like C
library wrappers are properly encapsulated as separate packages, things
tend to stay quite simple. Certainly simple enough for an SDL based
format to stay readable.

Of course there may be exceptions, but it's always better to put
pressure on people to simplify things instead of facilitating complex
structures (it makes me sick to look at certain Java or C# code bases
where people often have no chance to get a real overview anymore,
because the complexity can only be handled by the refactoring tools). Or
in other words, what might be a relief in the short term (the tool) may
be a terrible burden in the long term. Of course it also depends on the
user, but most examples that I've seen goes this way.

But even if we'd say a tool for managing package description complexity
is a good idea, will a generic XML tool really help much? I'd imagine
that a specialized tool is needed to bring much of a benefit - but in
that case the format doesn't really matter.