File names

Xoom folders utilise a well-defined, predictable naming convention for item files.

The convention is designed to work around the limitations imposed by different file systems with regards to case-sensitivity, case-preservation and the handling of special characters. These limitations vary across storage platforms. Our naming convention is best explained with an example.

Imagine a simple configuration containing: If saved as a Xoom folder, the folder and file structure would be as follows:
FolderRoot
  BundlerConfiguration
    BundlerConfiguration
      Break Dedication.X.xml
  Scheme
    Collection
      Assignment.1.xml
      Task.1.xml
  Setting
    Setting
      [Application]~Agents~AgentsManager~.52NEP.xml
      [Application]~Internal~CurrentTimeForDebug~.4GXRS3L.xml
All key values from each item's Xoom identity are used to construct its filename. In the above example, key values would be: When there are multiple keys, as in Setting, these are separated by ~. Any characters that are not permitted in a file name are replaced with an underscore.

To avoid name clashes, a unique sequence of characters is appended to the filename: for example .X in Break Dedication.X.xml. This sequence is calculated from the key values that constitute the file name so as to take account of the limitations of various file systems. It encodes any non-permitted characters that have been replaced by an underscore, and any capital letters. The sequence always begins with a full stop.

The reason why this procedure is necessary in the context of Service Optimization is that Windows file system is case-preserving and case-insensitive, whereas item Xoom identity is case-sensitive. For example, settings named "Forged" and "ForGED" would be two acceptable and completely unrelated settings in Service Optimization. By contrast, the files "Forged.xml" and "ForGED.xml" couldn't exist in the same Windows folder because the file system is case-insensitive and their names would clash. Consequently, capitals and non-permitted characters have to be removed. Replacing them with a calculated sequence makes their names unique, predictable and reconstructable even on file systems that are not case-preserving (i.e. both file names in the example above would be changed to "FORGED.XML" on such a file system).