Sent From: [log in to unmask]


At 11:44 PM 1/11/2001, Douglas Wood wrote: >I am looking to confirm through the HLA 1.3 draft specification text that >an attribute instance can be associated with no more than one region at >any given time. > >The DMSO 1.3 NG Programmers Guide specifies in section 10.5.1 that ``A >given attribute instance is only associated with one region at any given >time and the region must be specified on the appropriate routing >space.`` It seems to me that the 1.3 draft text is ambiguous on the >issue. There is language in the OMT specification (4.4.2 last paragraph) >that specifies an attribute can be associated with no more than one >routing space. But I could find no such statement in the IF specification >(or anywhere else) regarding associating an attribute instance with only >one region. Doug, [I should preface my comments with that this is my personal understanding/interpretation of the specifications. We typically work with the HLA RTI Verification Team on ambiguities and they may have differing insight/opinions than what I state below.] The Interface Specification 1.3 draft 10 (final 1.3 version and was approved by AMG) states (page 149, section 9.1): The following relationships, established in the FED, shall pertain to routing spaces: ..... A given class attribute shall be bound to at most one routing space. This answers your question if the specification states a class attribute (and an attribute instance) can be associated with only a single Routing Space, but it does not answer your question though if an attribute instance can be associated with more than one region. I am not sure if this is explicitly stated anywhere in the 1.3 specification, but it appears to be implied everywhere. Although there may be some convenience from the federate perspective, allowing multiple regions to be associated with an attribute instance provides an ``over-specification`` since anything represented in multiple regions can be represented by a single aggregated region. Is there a particular reason why you are looking for this capability? >Does the 1516 standard also restrict the associations between attribute >instances and regions? The 1516 text seemed equally ambiguous. The text >does not seem to indicate that multiple associations are forbidden, but >then again, it does not indicate that multiple associations shall be supported. In the 1516 specification the concept of Routing Spaces are effectively eliminated (one could consider that there is a single Routing Space with many dimensions). Due to the above change and some others, the 1516 specification supports the association of multiple regions with a single attribute instance (or attribute class, interaction class). The DDM services take a ``collection of attribute designator set and region designator set pairs`` (the key being the region designator SET). >As a side issue, I noticed a discrepancy between the 1.3 and 1516 DDM >specifications. The 1.3 DDM scheme allowed multiple extents to be defined >in a region. A coarse example would be a region that approximates a circle >with many rectangle extents or picture a region that specifies the black >squares of a chess board. My understanding of the 1516 DDM specification >is that there is no such capability to specify multiple extents within a >region. Each region has a single extent (i.e., each dimension has a single >lower and upper bound). If this interpretation is correct, how would the >given examples be supported without associating an attribute with multiple >regions? Since the 1516 supports the association of multiple regions this is not an issue (unless I am missing something from your concern). Hope this helps, Steve ------------------------------------------------------------- Steve Bachinsky voice: 703-333-5428 SAIC fax: 703-354-5398 5400 Shawnee Road, Suite 110 cell: 703-898-5989 Alexandria, VA 22312 email: [log in to unmask] epage: [log in to unmask] ------------------------------------------------------------- At 11:44 PM 1/11/2001, Douglas Wood wrote:

I am looking to confirm through the HLA 1.3 draft specification text that an attribute instance can be associated with no more than one region at any given time.
 
The DMSO 1.3 NG Programmers Guide specifies in section 10.5.1 that "A given attribute instance is only associated with one region at any given time and the region must be specified on the appropriate routing space."  It seems to me that the 1.3 draft text is ambiguous on the issue.  There is language in the OMT specification (4.4.2 last paragraph) that specifies an attribute can be associated with no more than one routing space. But I could find no such statement in the IF specification (or anywhere else) regarding associating an attribute instance with only one region.

Doug,

[I should preface my comments with that this is my personal understanding/interpretation of the specifications. We typically work with the HLA RTI Verification Team on ambiguities and they may have differing insight/opinions than what I state below.]


The Interface Specification 1.3 draft 10 (final 1.3 version and was approved by AMG) states (page 149, section 9.1):
The following relationships, established in the FED, shall pertain to routing spaces:
...
A given class attribute shall be bound to at most one routing space.

This answers your question if the specification states a class attribute (and an attribute instance) can be associated with only a single Routing Space, but it does not answer your question though if an attribute instance can be associated with more than one region. I am not sure if this is explicitly stated anywhere in the 1.3 specification, but it appears to be implied everywhere. Although there may be some convenience from the federate perspective, allowing multiple regions to be associated with an attribute instance provides an "over-specification" since anything represented in multiple regions can be represented by a single aggregated region. Is there a particular reason why you are looking for this capability?


Does the 1516 standard also restrict the associations between attribute instances and regions? The 1516 text seemed equally ambiguous.  The text does not seem to indicate that multiple associations are forbidden, but then again, it does not indicate that multiple associations shall be supported.

In the 1516 specification the concept of Routing Spaces are effectively eliminated (one could consider that there is a single Routing Space with many dimensions). Due to the above change and some others, the 1516 specification supports the association of multiple regions with a single attribute instance (or attribute class, interaction class). The DDM services take a "collection of attribute designator set and region designator set pairs" (the key being the region designator SET).


As a side issue, I noticed a discrepancy between the 1.3 and 1516 DDM specifications.  The 1.3 DDM scheme allowed multiple extents to be defined in a region. A coarse example would be a region that approximates a circle with many rectangle extents or picture a region that specifies the black squares of a chess board.  My understanding of the 1516 DDM specification is that there is no such capability to specify multiple extents within a region. Each region has a single extent (i.e., each dimension has a single lower and upper bound). If this interpretation is correct, how would the given examples be supported without associating an attribute with multiple regions?

Since the 1516 supports the association of multiple regions this is not an issue (unless I am missing something from your concern).

Hope this helps, Steve




-------------------------------------------------------------
Steve Bachinsky               voice:  703-333-5428          
SAIC                          fax:    703-354-5398          
5400 Shawnee Road, Suite 110  cell:   703-898-5989          
Alexandria, VA 22312          email:  [log in to unmask]     
                             epage:  [log in to unmask]
-------------------------------------------------------------


To unsubscribe from the Z-ARCHIVE-SIW-CFI list, click the following link:
https://discussions.sisostds.org/index.htm?SUBED1=Z-ARCHIVE-SIW-CFI