-
Key: DSS2-105
-
Legacy Issue Number: 5234
-
Status: closed
-
Source: MITRE ( Ms. Susan Symington)
-
Summary:
Text in this section currently states, "The RTI shall be responsible for
attempting to find an owner for instance attributes that are left unowned
(either via registration, federate resignation, or some form of divestiture).
The RID provided to an RTI may allow the federation to control how often or for
how long an RTI will attempt to find an owner for unowned instance
attributes." This text should not be considered to be part of the standard.
The first sentence states a requirement that the RTI be responsible for
something without explaining the mechanism by which the RTI is expected to
fulfill this requirement. The second sentence, about the RID, is simply out of
place in the standard, as it refers to implementation-specific behavior.Without explanation of the mechanism by which the RTI is expected to fulfill
{x}
its responsibility, this text in its current unqualified form violates a
guiding principle of the HLA specification, which is the principle of minimum
astonishment. If no federates in a federation execution are using some aspect
of the HLA specification (such as, in this case, ownership management) then no
federates in the federation execution should receive service invocations
related to that aspect of the specification that is not in use. In particular,
this text would result in the following circumstance: Suppose there is a
federation execution in which no ownership management services are explicitly
invoked by any federate and there are two attributes, x and y, available at
object class A.
Fed1 invokes Publish Object Class Attributes (A,)
{x, y})
Fed2 invokes Subscribe Object Class Attributes (A,
Fed2 invokes Publish Object Class Attributes (A {x, y})
Fed1 registers an instance, object1, of class A
Fed2 discovers object1
Fed2 would receive a Request Attribute Ownership Assumption callback for
instance attribute y of object1. This service invocation would be astonishing
to a federate such as federate 2 that is not using ownership management.Similarly astonishing callbacks would also be received by eligible federates in
the following two situations that do not involve any explicit use of ownership
management:- an owning federate unpublishes a class attribute, thereby causing a
corresponding instance attribute to become unowned - a non-owning federate begins publishing a class attribute at the known class
of an object instance that has a corresponding instance attribute that is
unowned.
In other issues that we raise with respect to IEEE 1516.1-2000 (interpretations
for Unconditional Attribute Ownership Divestiture and Resign Federation
Execution), we suggest text that explains the mechanism according to which the
RTI is expected to fulfill its responsibility for attempting to find an owner
for unowned instance attributes when they become unowned as a result of the use
of an explicit ownership management service or directive. However, there is no
suggestion that the RTI should try to find an owner for unowned instance
attributes when they either become unowned as a result of registration or
unpublishing a class attribute, or when a non-owning federate that was not
previously eligible to own the unowned instance attribute becomes eligible to
do so. - an owning federate unpublishes a class attribute, thereby causing a
-
Reported: DSS 1.1 — Tue, 30 Apr 2002 04:00 GMT
-
Disposition: Resolved — DSS 2.0
-
Disposition Summary:
Delete the text as suggested.
-
Updated: Fri, 6 Mar 2015 20:58 GMT
DSS2 — Overview of Ownership Management: RTI responsibilities
- Key: DSS2-105
- OMG Task Force: Distributed Simulation V2.0 FTF