which data file format is better for storing setup information? XML, ASCII or Binary?

[Jaggs]

Hello,

Our application is using cluster, string, Integer and other data types and storing them in ASCII files.  We are using flatten to string function and storing it to the text file.  However, going ahead we want to migrate to XML file format.  Is it a good idea?  What would be the pros and cons?

Thanks.

[smercurio_fc]

Technically, an XML file is an ASCII file - it's just an ASCII file with a specific format. That said, it sort of depends on the information you're saving as well as how you intend to access that information.

If you do not want the configuration information to be human-readable or human-editable with a simple text editor, then you will want to either have a binary file or keep using the flatten to string which gives you a string looking like gibberish.

The XML format is a good format, but you will need to decide on a document structure. If you use LabVIEW's built-in functions that flatten data to XML, you're pretty much stuck with the format they provide, since if you change the format you will likely not be able to read it using LabVIEW's built-in functions. If you use your own structure then you will need to use XML functions to read the document using the DOM. LabXML is one possibility, and I've used it for a number of years. The caveat is that it's Windows-specific. It also hasn't been updated in a while. One warning: If your XML file is large, reading and parsing can take a while.

The INI format is also another popular format. It's fairly standard, but it is limited due to its simplistic structure. The advantages are that LabVIEW has built-in functions to read/write INI files, and while they are bloated, they work. If you're looking to store information from clusters, strings, etc, you should take a look at OpenG's functions which provide functions for reading/writing clusters to INI files.

[Jaggs]

Thanks for your reply.  We are using setup information to store in the files.  The file size is not large.  Cuurently we are using ASCII format and it is taking around 20KB.  XML may take 5-10 times more space which still will be less.

[Matthew_Kelton]

If you are using LabVIEW's Flatten to String function, you are storing your data as binary, even if you are sending a string to the file writer.

The issues you will run into using this method or any of the canned LabVIEW XML VIs:  If your data type changes, your files can't be read in any more.  You mentioned you have clusters.  If you add an element or take one away, the old files won't be read in anymore.  You would have to store old versions of the data type and file reader and then convert the old data type to the new data type.

The nice thing about OpenG's INI functions is they take variant's, so you can pass complex data structures and it will write the file.  If the data type changes, as long as it can be coerced into the format, it will still be read in.  If you pass a cluster and a value is missing from the INI, the default is used.  If there is an extra value in the INI, it's just skipped.  So, your reader and writers can be updated without as much concern about supporting old data files.

One method you can do if you want to use binary is the "TLD" method.  TLD stands for Type, Length, Data.  I use an enum for the Type.  The Length is just the length of the Data which follows, and then the data is the binary data.  If I change a data type, then I create a new enum value (always has to be added to the end of the list to maintain value consistency with the old files).  This way, the reader can still handle the old data type and convert it into the new data type in whatever method is necessary.  It can also completely ignore it if desired.  I usually process clusters as individual items so I don't have to save old versions of the cluster.  It works quite well and only adds a few bytes per data item.  The big caveat is you have to remember to update your file writer and reader whenever you change a datatype or add a new value.

[mikeporter]

Given the choice between XML, ASCII or Binary, I'd have to say:

😧 None of the above.

The best solution is to store setup information in a database. Databases are secure, easy to use, application independent and platform independent.

Mike...

[smercurio_fc]

---

mikeporter wrote:

The best solution is to store setup information in a database. Databases are secure, easy to use, application independent and platform independent.

---

Aside from the secure part (which I'm not sure is a requirement in this case), the same can be said for XML files.

[DFGray]

I am a bit late to this party, since I just got back from vacation, but would like to throw my 2 cents in.  Unless you know you have a simple configuration and that it will stay that way, I would recommend a self-describing binary file format.  There is no need to roll your own, as several are available (although you will need to specify the internal structure).  I prefer HDF5, since I am familiar with it, but you may also want to check out TDMS (LabVIEW's new, native, self-describing file format) or CDF.  All should work on any platform supported by LabVIEW.  These are all essentially database lite.  Using such a file format allows you to do some interesting things, such as embedding configuration information in a data set, or data sets in your configuration.

Whatever you use, make sure you have a data browser available for it.  This makes off-line modification and format checking much easier.