IBM® WebSphere® Presence Server Component conforms to the Presence data model standard.
According to the data model, specified in IETF RFC 4479, each presentity has only one document, and–if possible–each document should have only one <person> element. Therefore, a presence composer should merge multiple <person> elements coming from different sources into one <person> element. Similarly, there should be only one <device> element per physical device and only one <tuple> element for a given contact, and the presence server should merge these elements too.
The RFC also stipulates that the presence composer may not always be able to merge information from multiple sources if ambiguities exist. Although a presence composer may be able to resolve ambiguities in some cases, in most cases it is best left to the watcher to resolve the ambiguity, by applying application-specific logic. Therefore, Presence Server does not try to resolve ambiguity. If information from multiple sources is ambiguous, that is, may contain conflicting information, Presence Server does not merge the conflicting <person>, <tuple>, or <device> elements. Instead, it keeps the original elements as distinct occurrences of the same element. The decision whether to merge is done separately per element. For example, Presence Server might merge the multiple occurrences of the <device> elements of device A but keep the distinct occurrences of <device> elements of device B because of ambiguity.
Presence Server attempts to merge all <person> elements, all <device> elements that have the same <deviceId> child element, and all <tuple> elements that have the same <contact> child element. <contact> elements are considered the same if the contact itself is the same, and the Priority attribute (if it exists) is the same.
The decision as to whether the elements can be merged is done by comparing the child elements. If there is no overlap between the child element types, that is, each of the merge candidates has different types of child elements, Presence Server can merge the elements. If there is an overlap, that is, child elements of the same type exists in more than one of the merge candidates, Presence Server merges only if these child elements are equal. Equality of child elements follows the definition in the document object model (DOM) and tested with the DOM isEqualNode method. In short, nodes of the same element type are considered equal if they have the same attribute key-value set (regardless of the order of the attributes within the element tag), and the child nodes are equal, that is, same number of child nodes and contain equal nodes at the same index.
<tuple id="eg92n8"> <contact priority="1.0"> mailto:someone@example.com </contact> <status> <basic>open</basic> </status> <rpid:status-icon> http://example.com/mail.png </rpid:status-icon> </tuple> <tuple id="hgy7y1"> <contact priority="1.0"> mailto:someone@example.com </contact> <status> <basic>open</basic> </status> <rpid:class>email</rpid:class> </tuple>
<tuple id="eg92n8"> <contact priority="1.0"> mailto:someone@example.com </contact> <status> <basic>open</basic> </status> <rpid:status-icon> http://example.com/mail.png </rpid:status-icon> <rpid:class>email</rpid:class> </tuple>
When comparing <note> elements appearing within <tuple>, <person> or <device> elements, the language (lang) attribute is taken into consideration. Note that elements having different lang attributes are not considered conflicting, and can be merged.
According to the Rich Presence Information Data (RPID) and Presence Information Data Format (PIDF) schemas, no child elements of <person>, <tuple>, or <device> can occur more than once (except for <note>). However, custom elements may be added that do occur more than once. When comparing the elements in this case, the comparison of child elements that occur more than once is done with the order preserved.