The add_publisherAssertions API call causes one or more
publisherAssertions to be added to an individual publisher’s assertion
collection. See Appendix A Relationships and Publisher Assertions
describing relationships and the API get_publisherAssertions for more
information on this collection.
The publisher must
own the businessEntity referenced in the fromKey, the toKey, or
both. If both of the businessKey values passed within an assertion
are owned by the publisher, then the assertion is automatically complete
and the relationship described in the assertion is visible via the
find_relatedBusinesses API. To form a relationship when the
publisher only owns one of the two keys passed, the assertion MUST be
matched exactly by an assertion made by the publisher who owns the other
business referenced. Assertions exactly match if and only if they:
1.
refer to the same businessEntity in their fromKeys;
2.
refer to the same businessEntity in their toKeys;
3.
refer to the same tModel in their tModelKeys;
4.
have identical keyNames; and
5.
have identical keyValues.
When a publisherAssertion being added references a
checked relationship system using the tModelKey in the contained
keyedReference, the reference MUST be checked for validity prior to
completion of the add, or the node must return E_unsupported, indicating
it does not support the referenced checked relationship system.
Validation of a relationship system reference entails verification that
the reference is valid according to the validation algorithm defined for
the relationship system and described by its tModel. For cached
checked relationship systems, the validation algorithm verifies that
referenced keyValues are in the set of valid values for the relationship
system.
For registries supporting the subscription APIs at
any node, it is necessary to track a modified date for publisherAssertion
elements so that nodes have the necessary information for responding to
subscription requests involving find_relatedBusinesses and
get_assertionStatusReport filters.