serializer should accept/use Zorba_SerializerOptions

[Chris Hillery]

The Zorba API defines Zorba_SerializerOptions, which contains values for all known serialization parameters (and typedefs enums for all legal values for those parameters). It also contains a method to convert string parameters/values appropriately.

The Zorba serializer (src/api/serialization/serializer.cpp) does not use this class, however. It defines an entirely redundant set of variables and enums for all these values, and an entirely redundant method to convert parameter/value strings. Then, there is src/api/serializerimpl.cpp, which contains methods to convert between those enums, but also ludicrously contains setSerializationParameters() which converts Zorba_SerializerOptions to internal serializer values by turning the enum values back into string parameter/value pairs and passing them to the internal serializer. This is a great deal of wasted code, and it makes adding new serialization parameters a nightmare.

[Matthias Brantner (matthias-brantner)]

When changing this, please keep the following two things in mind:

- The Zorba_SerializerOptions are also used in the C API.
- The encodings parameter should be an arbitrary string to allow for more encodings than utf8 and utf816.

[Chris Hillery (ceejatec)]

>
> - The Zorba_SerializerOptions are also used in the C API.
>

Do you mean the C++ API, or literally the C API? I don't recall it in
XQC... (relevant because I'd like to have it throw exceptions for bad
values)

If you mean "don't make any backwards-incompatible changes", then yes,
understood - my intent is to eliminate the internal redundancy and leave
the existing public API as it is.

- The encodings parameter should be an arbitrary string to allow for more
> encodings than utf8 and utf816.

This would be a backwards-incompatible change, most likely, and so would
have to wait for Zorba 3.0.

[Matthias Brantner (matthias-brantner)]

My comments are void if you don't want to make backwards-incompatible changes.