View Issue Details

IDProjectCategoryView StatusLast Update
000646110000-003: Address SpaceSpecpublic2021-03-01 16:42
ReporterWolfgang Mahnke Assigned ToJeff Harding  
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionfixed 
Summary0006461: Clarification on subtyping symmetric references
Description

I have not found any restrictions on subtyping symmeritic references, which implies that you can have a asymmetric reference as subtype.
We already do this with abstract symmetric ReferenceTypes.

The behaviour of symmetric and asymmertic ReferenceTypes is different when browsing them, one is always handled as forward direction, for the other there is a forward and inverse direction.

That implies, that if someone does not use the symmetric ReferenceType directly, but a subtype, the behavoiur is different. Is this expected behaviour, and if yes, should we write this explicitly into the spec?

The same problem occures when subtyping a asymmetric reference with a symmetric one. When you try to follow the inverse direction, you will not get the reference since the symmetric one does not have an inverse one.

TagsNo tags attached.
Commit Version
Fix Due Date

Activities

Jeff Harding

2021-02-09 18:02

developer   ~0013715

Once a Reference type is concrete all subtypes shall not change the symmetric / asymmetric definition of its parent.
Abstract types can't assume anything about the symmetry of the concrete subtypes.

Jeff Harding

2021-02-24 19:21

developer   ~0013808

Added clarification "A subtype of a concrete ReferenceType shall not change the Symmetric Attribute definition of its parent type" to 5.3.2 ReferenceType NodeClass Attributes.

Randy Armstrong

2021-03-01 16:42

administrator   ~0013848

Reviewed in F2F March 2021.
Text updated in document.

Issue History

Date Modified Username Field Change
2021-02-03 14:32 Wolfgang Mahnke New Issue
2021-02-09 18:02 Jeff Harding Note Added: 0013715
2021-02-09 18:03 Jim Luth Assigned To => Jeff Harding
2021-02-09 18:03 Jim Luth Status new => assigned
2021-02-24 19:21 Jeff Harding Status assigned => resolved
2021-02-24 19:21 Jeff Harding Resolution open => fixed
2021-02-24 19:21 Jeff Harding Fixed in Version => 1.05
2021-02-24 19:21 Jeff Harding Note Added: 0013808
2021-03-01 16:42 Randy Armstrong Status resolved => closed
2021-03-01 16:42 Randy Armstrong Note Added: 0013848