3

I've worked on projects that have very complex XML configuration, and one problem that's faced is maintaining the internal consistency of the XML.

In this case I don't mean the strict XML schema consistency, but rather the higher level relation between the nodes used. Most problems were caused by implicit linking between information encoded in the XML, and implicit relation of that information to the codebase. Examples might be:

  • XML node data implicitly linked to enums in code
  • Business objects in the same config that are related (in that they share information that needs to be consistent) without any explicit relation between them
  • Code in XML to be compiled and parsed at runtime

It struck me that a) this might become a practice of increasing frequency and b) that in some cases we're implicitly creating a new coding language that's not compile-time checked -- and in fact has few checks at all until it's run.

Is anyone else out there facing similar scenarios, and are there any tools or approaches that make the problem more tractable? I'd like some general examples that are technology-agnostic -- my own specific experience has been with C# and with config for proprietary systems.

Note: although I have an answer to this below, I've no intent of taking my own as the final answer.

Tim Barrass
  • 4,813
  • 2
  • 29
  • 55

4 Answers4

2

This will greatly depend on languages/frameworks/tools you're using for your project.

Using XML for configuration can be really problematic because it cannot be compile time checked.

For example, when using Java and Spring Framework, there exists an Eclipse plugin called Spring Tool Suite which can do synchronization checking between XML configuration and the actual code.

But this is just one example for a specific language and a specific framework. You should try to find out if something similiar exists for your scenario.

By the way, if you let us know what technologies you're using, we might be able to assist you more.

darioo
  • 46,442
  • 10
  • 75
  • 103
  • thanks. I actually wanted to keep this language and system agnostic, as it's to do with business rules really. That said, I'll add a comment on what I'm working with generally. – Tim Barrass Dec 09 '10 at 09:27
2

Did you try Schematron? http://www.schematron.com/

It's a higher level language targeted at validating XML semantically, not just syntactically.

See also Wikipedia: http://en.wikipedia.org/wiki/Schematron

David Peleg
  • 394
  • 2
  • 9
2

I use automated functional tests to ensure the data integrity of our default config at work. I don't know that the problem you describe is necessarily dependent on the config format being XML. That being said I would suggest:

  • You don't use XML as a config format. (Google can give you the reasons)
  • Tight coupling through the implicit use of enums or any other constructed values are just as bad in a config as they are in code.
  • Code that get's pulled from a config and executed makes me cringe. Is it in a config so that it can be overridden? If so that's a huge vector for bugs, undefined behavior and potential security issues.
  • the business objects issue also sounds like bad tight coupling.

You may not be able to do anything about XML as the config format, the bad coupling, or the execution of code from config. You can mitigate the risk by creating a suite of functional tests that ensure:

  • the enums are valid
  • the code is compilable, executable, doesn't contain evals, rpc calls, calls no functions, or whatever other analysis checks you want to add.

You can also sometimes help change by providing an alternative (config or config entries).

dietbuddha
  • 8,556
  • 1
  • 30
  • 34
  • Thanks for the response -- I've been wondering about how to compose tests. I wondered about tagging xml nodes and code with matching tags, for example, so that an automated test might be able to match them up. Do you do anything special to compose your tests? – Tim Barrass Dec 14 '10 at 20:17
  • btw: very much agreed on the code-in-config being a vector for all sorts of nastiness. – Tim Barrass Dec 14 '10 at 23:01
  • 1
    Instead of tagging the xml nodes and code, you may want to think about removing the tight coupling. My tests are usually a fix of functional tests, variant tests and unit tests of particular pieces of code. – dietbuddha Dec 15 '10 at 05:32
  • Aye, there's a real tension here between doing what seems right and what seems possible -- in a large production system. What concerns me the most is that it takes us away from a brownfield refactoring that might actually leave us with a better system. – Tim Barrass Dec 15 '10 at 22:20
1

A good link on from @David Peleg's is Topologi, which offer products to check XML, including "business rules" checks.

Tim Barrass
  • 4,813
  • 2
  • 29
  • 55