1

The "classic" approach I know to store some configuration information in an XML file looks basically like this:

<properties>
  <entry key="hello">Hello</entry>
  <entry key="world">world</entry>
</properties>

or maybe this:

<properties>
  <entry key="hello" value="Hello"/>
  <entry key="world" value="World"/>
</properties>

We're currently trying to come up with a simple and flexible configuration file for internal use that will be read by several scripting languages as well as possibly some C# and C++.

I'm wondering whether the above approach is the "way to go", or whether an approach with "ad hoc" elements would yield a file that is more straightforward to extract information from:

<properties>
  <hello>Hello</hello>
  <world>World</hello>
</properties>

Certainly, any XPath expressions would get shorter, e.g.:

"//properties/hello" 
vs.
"//properties/entry[@key='hello']/@value

This would make scripts that quickly grab some info out of the file easier to read I think.

What pro/con would these forms have wrt. easily and succinctly grabbing values out of it? (vs. maintainability, ...)

I'm not overly concerned with a schema for this, and please lets not get into XML for configuration files, why? .

Community
  • 1
  • 1
Martin Ba
  • 37,187
  • 33
  • 183
  • 337

2 Answers2

1

Probably the main difference two take into account between the two structures is that you can repeat elements but not attributes, also as you mentioned it's easier to parse only elements than elements and attributes. Attributes only make more sense when they are unique for the whole node, for example in we wanted to store clients and their addresses:

best approach:

<client id="123">
   <address>address123</address>
   <address>address456</address>
</client>

not that good, because potential inconsistencies especially if there is no schema validation:

<client>
   <id>123</id>
   <address>address123</address>
   <address>address456</address>
</client>

worst approach, difficult to extract info from:

<client id="123" address1="address123" address2="address456">

In the case of a property file as you are probably more interested in hierarchy, in my opinion, a mostly element-based structure should do a good job.

Jayvee
  • 10,670
  • 3
  • 29
  • 40
1

For general advice on element vs attributes, see XML elements vs XML attributes. This answer will instead focus on specific vs generic XML element names.

Specific vs Generic XML Element Names

Here are some guidelines on choosing between specific vs generic element names in XML:

Specific element names

 <FirstName>John</FirstName>

Use specific element names when...

  • Your domain has a relatively fixed vocabulary.
  • You favor stability over open-ended flexibility.
  • An industry standard vocabulary or schema exists with specific names.
  • You want to be able to write clean content models in any XML schema.
  • You want XPaths to be cleaner.

Generic element names

 <entry key="FirstName">John</entry>

Use generic element names when...

  • None of the reasons for specific element names apply.
  • The vocabulary term is lexically incompatible with the lexical rules of XML. (If it might have embedded spaces, start with a number, etc.)

Generally, you should use specific element names. Generic key-value stores (which are often a good fit for configuration files) are an exception to this general guideline.

Community
  • 1
  • 1
kjhughes
  • 106,133
  • 27
  • 181
  • 240