We have a system whose behavior is defined by a number of XML files.(Roughly 50 different XML files each of which governs the behavior of a sub system.)
The XML files for legacy reasons are in a custom format,meant for easy consumption by various components in the system.
The custom format is not very intuitive and readable for a human.(Which is also an important consideration for us).
So how do we tackle this readability issue?
I feel that an intuitive UI written on top of these XML files should do the job.
However my co worker feels that replacing XML files with DSL is a better idea, since they can be both intuitive and machine readable.
Is this a good idea or an overkill? I feel that getting DSL right is extremely hard compared to say a UI. But I could be wrong.
Any help would be greatly appreciated. Thanks.
An XML-to-XML translation is a half-way solution and is probably the approach I’d use.
A UI has to be very complete before it’s a replacement for a text-based description of behaviour, and common text-based idioms such as copy & paste, search & replace etc. are awkward to implement with good usability in a UI.
However, a full-blown DSL with a custom parser is probably a step too far, particularly if there isn’t parser or compiler experience in multiple members of the team. Don’t get me wrong – I don’t think people should be afraid of parsers, I’m a compiler engineer myself – but it’s a fact that some folks are fearful, and if the parser isn’t done right, it can get messy quite quickly.
So, I’d advocate designing an idealized XML format, and write a tool that transforms that format into your real XML format either with XSLT (if it’s easy – I wouldn’t get too deep into XSLT functions etc.) or a simple translation app.
There are lots of advantages to having a readable text format for specification: ad-hoc editing is easy (you only need notepad), diffs from source control are readable, snippets can be emailed around, etc. Getting a UI that has usability and functional parity with a text format is not easy.