#6 XML-Output

Abook supports different output formats, which
transformations are hardcoded into the sourcecode. Due
to some experiments, I noticed, the there are some
complications due to changing formats (ldif) and lack
of information (abook2csv).

My suggstion is, to store all informations in some kind
of XML format, which has several advantages:
* Transformation could be easier customised
* One can easier extend the ways to transform the data
* Source code gets smaller, because all trnasformations
can be ripped off

Since everything has two sides, so it's here:
* XML-Suppot has to be implemented from the scratch
* One has to have extra tools to transform

[Jaakko Heinonen]

Logged In: YES
user_id=71293

* Needs also code for proper character set conversion

[Raphaël]

There is already an internal DB structure implementation which is unlikely to change.
XML output would be better handled by an external tool assuming abook generates a nice output.

And TAB-delimited CSV ("allcsv"), "vcard" or even "custom" formats are here for this purpose : not as generic as XML could be, but sufficiently predictable, consistent and exhaustive to let anyone convert this output to XML or anything else.

Overall, XML doesn't sound adequate for exporting abook contacts, in 2025
- because JSON, while less powerful and expressive, is more readable which make it more suitable for human-related data (although it lacks commenting ability)
- Because bundling a XML library in a minimalist software like abook, during this 2025 JSON-oriented decade seems unfit
- "custom" format, based on placeholders, sounds even more generic than any hardcoded XML semantic (using a template and the power of placeholders, you could output custom XML based on your own schema)