This is the first in a series of dev discussions related to the activity event model that will be used as part of the BAM capability.
This topic relates to whether we should be looking to serialize the activity events using xml or json. This question may be interrelated to some of the other discussions (e.g. if a current 'standard' schema was adopted, then that may dictate the answer), but it would also be good to consider as a general question initially.
(a) xml provides a standard language independent means of exchanging information in an interoperable manner. XML schema can be used to ensure a valid structure.
(b) json - language independent (with caveats[*]), simplified representation of information, although does not have a notion of schema for use in describing/validating the format
The serialized form of the activity events will only be used in two situations - reporting the activity events, and then querying the events to potentially be displayed in a web app. Internal processing of the events would use the Java object representation, which leds to the requirement that the de-serialization into Java objects needs to be efficient.
[*] If using derived types (e.g. sub-types per type of activity), then json does not define how this should be represented. jackson, the json library that would most likely be used (if json is selected), annotates the element with the Java class name, which makes it Java (and jackson) specific. Another possibly more language independent appoach would be to define a field in the base class that identifies the type in a generic way, and then implement a resolver class that can translate that field value into the appropriate class - but just need to consider how best to support extensibility.
I would vote for the JSON format, at least, from the web app's perspective. Take the GWT based web application, desrialization json is far more easily then XML. In reporting the activity events, if we are sending those events in batch mode, I believe JSON format size is smaller than XML.
|Retrieving data ...|