Why xml_storage?

[cpuguy83]

After spending more time than I'd like writing code to script changes to xml_storage versions for ConfigItems... including reading from and writing to... taking input as something human readable/writeable and making the output human readable.... I have to ask, why xml_storage for custom fields/versions?

Seems to me it would be far easier to have a table to define your custom fields (id, name, parent_id, type), with a join table to join fields to a class, then write versions to a table with (id, config_item_id, [ci_field]).... I realize this kind of how versions are done in xml_storage, but why the format that it's currently in (tagkeys, arrays with nils at index 0, etc).

[jojo]

XML is more flexibel and you'll have a "ontainer" with all the data from one CI version

[cpuguy83]

But wouldn't you just write a converter to go from a relational table structure to XML?