Issues for Mailing list of the Robotic Localization Service 1.0 (RLS) Finalization task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 12916: create sub packages
Issue 12917: Sequence diagrams should be added
Issue 12918: Separate XMI definition from RLS specification document.
Issue 12919: Figure 3 - Relative and Mobile c oordinate reference system
Issue 12920: The navigability notation(arrow head) should be added as follows
Issue 12921: The association end name should be added as follows
Issue 12922: add an explanatory note
Issue 12923: Table 5 RelativeDatum class
Issue 12924: Figure 4 - Mobile CRS operations
Issue 12925: Figure 5 - Identity information
Issue 12926: 7.3.2 Identity Information
Issue 12927: Figure 6 - Error Type
Issue 12928: Figure 7 - Error information
Issue 12929: Figure 9 - RoLo Architecture
Issue 12930: Figure 10 - RoLo Data Operation
Issue 12931: Figure 11 - RoLo Data format
Issue 12932: 7.4.1 Common data format TypeI.Cartesian coordinate system
Issue 12933: 7.4.1 Common data format TypeII.Polar coordinate system
Issue 12934: Figure 21 - RoLo Ability and RoLo Parameter Set
Issue 12935: Figure 22 - RoLo Service
Issue 12936: Table 132 - Stream Parameter Set class
Issue 12937: Table 133 - Stream Ability class
Issue 12938: Table 134 - RoLo Stream class
Issue 12939: Sample C++ Header
Issue 12940: Typos
Issue 13106: Relative/Mobile CRS name is confusing
Issue 13107: Relative/Mobile operations are not well defined
Issue 13108: SymbolicCS/CRS name is confusing
Issue 13109: Possible inconsistency between RoLo Data class attributes
Issue 13110: RoLo Attribute Set definition typo
Issue 13111: Possible inconsistency between RoLo Attribute Set attributes
Issue 13112: Typo in 6.3.4 Robotic Localization Architecture
Issue 13113: Typo in Position Element Operation class description
Issue 13114: RoLo Attribute Definition Set definition typo
Issue 13115: The union of a documents
Issue 13116: Change the class name of RoLo Architecture
Issue 13117: Angle unit representation
Issue 13118: Posistion description in Type II
Issue 13119: Name of Type II coordinate system
Issue 13120: Name of Orientation
Issue 13121: Definition of orientation in Type I, II, III
Issue 13122: Filter package for the Issue #12916
Issue 13129: posSpecRef in Error Element (Figure 9/Table 49)
Issue 13130: Mismatch in Error Type (Figure 6) and Error Information (Figure 7) definitions
Issue 13131: Missing 'public:' declaration in PSM RelativeDatum definition
Issue 13143: Typo in Position Element Concatenated Operation class definition
Issue 13144: Definition mismatch for Service Ability class in Figure 22 and Table 139
Issue 13145: Figure 8 may accompany an object diagram
Issue 13184: Filter Condition should be reduced and move to annex as informative
Issue 13185: Hierarchy of Error can be reduced
Issue 13186: XML mapping of RoLo Data and RoLo Element
Issue 13187: Hierarchical relationship for instances of CRS and RoLo Data Spec
Issue 13317: Simplication of Error Type (Figure 6):
Issue 13318: Typo in Table 22 (RoLo SymbolRef)
Issue 13319: Obligation of 'values' attribute of Matrix (Figure7/Table36)
Issue 13320: The type of 'usesOperation' attribute of RoLo Data Transformation (Table62)
Issue 13321: Association between RoLo Parameter Set and RoLo Parameter Definition (Figure 21)
Issue 13322: Inability of representing range values (Figure21/Table120)
Issue 13426: Conformance shall be specified in detail
Issue 13427: Some references are missing
Issue 13428: Terms and Definition shall be added
Issue 13429: Symbol should be described
Issue 13430: Some organization missing in "6.1 Supporting Organizations"
Issue 13431: Names missing in "6.2 Acknowledgements"
Issue 13432: Typos in 6.3 Background
Issue 13433: Overview in 6.3 Background needs to be modified
Issue 13434: Some description on Coordinate System usage shall be added
Issue 13435: Ambiguity in 'rla' attribute description in RelativeDatum class
Issue 13436: 'inStream' attribute in MobileDatum class shall be an object
Issue 13437: 'numDists' attribute in Lineare Mixure Model class may be unnecessary
Issue 13438: Typo in RoLo Attribute Definition class description
Issue 13439: Structural change for RoLo Service class
Issue 13440: Typo in Service Ability class description
Issue 13441: Inconsistency between PIM and PSM namings
Issue 13442: Inconsistency in class names
Issue 13443: Typo: argument type for methods in RoLo Service class
Issue 13451: Missing references
Issue 13998: RLS - typos
Issue 13999: (7.4.1) Timestamp for common data types
Issue 14000: (Annex A) Mapping between PIM and C++ PSM is not clear
Issue 14001: (7.5) In the filter condition section
Issue 14002: 7.5) Filter condition requires naming of RoLo data elements. However, the naming rules are not clear.
Issue 14003: Fig3,Tbl9,Fig22,Tbl134,Tbl140) Mobile Datum class, RoLo Stream class and RoLo Service
Issue 14004: Fig5,Fig9) RoLo Symbolic Position class and RoLo Position class
Issue 14005: (Fig7) Matrix class is specified as "DataType" but this is unnecessary
Issue 14006: Tbl119-Tbl129)
Issue 14007: Tbl124) Specifying RoLo Attribute Singlevalue class as an enumeration
Issue 14008: 7.6) RoLo service is described to have only one output stream, but this is sometimes too difficult to use
Issue 14009: (Tbl135/Tbl136)
Issue 14010: (Tbl135/Tbl136) The 'connect' methods
Issue 14011: Tbl134) The behavior of setParameter method in RoLo Stream class is unclear
Issue 14012: Tbl130) Two types of data passing mode specified in StreamType enumeration is not clear
Issue 14013: Tbl130,Tbl136) The 'setData' method in InStream class
Issue 14014: (C++-PSM) Methods shall better send return codes as exceptions
Issue 14015: Subset specifications (Fig22)
Issue 14016: Parent class wrong for RelativeCRS

Issue 12916: create sub packages (rls-ftf)

The package division
 In RLS specification, there is only one package named RLS.
 I think that it should be divided into some sub packages.
 Ex.Coordinate system package, Data Format package, Filter package, Service package, etc.

Reorganize the classes into three sub packages, Architecture package, Data
Format package, and Interface package. Architecture package includes classes
defined in section 7.3, Data Format package includes classes defined in section
7.4 and Interface package includes classes defined in 7.5.
Also, rename the titles of section 7.3 to 7.5 in order to make it clear which
package each class belongs to.

In RLS specification, there is no sequence diagram.
 I think it is difficult to understand behavior. 
 So I think it would be better if sequence diagrams were added.

The division of documents
 The RLS Specification FTF Beta1(dtc/2008-07-01) includes XMI definition(Annex B).
 I think that the XMI definition had better separate from RLS specification document.

The association between Relativedatum and ReletiveCRS should be reverse.
-In RelativeDatum class, attributes(rla,base) should replace to derived attributes.
-In MobileDatum class, attributes(inStream) should replace to derived attributes

-RoLo Architecture class side of association between RelativeDatum and RoLo Architecture.
 -RoLo Data class side of association between RelativeDatum and RoLo Data.
 -InStream class side of association between MobileDatum and inStream.

 -rla : RoLo Architecture class side of association between RelativeDatum and RoLo Architecture.
 -base : RoLo Data class side of association between RelativeDatum and RoLo Data.
 -inStream : InStream class side of association between MobileDatum and inStream.

Because the following association is meanings to limit relations defined in superior,
 we should add an explanatory note.
   Relativedatum - ReletiveCRS
   RelativeCartesianCRS - SC_CertesianCS
   RelativePolarCRS - SC_PolarCS
   MobileCRS - MobileDatum
   MobileCartesianCRS - SC_CertesianCS
   MobilePolarCRS - SC_PolarCS

-The last of Description is over in "Holds a RoLo Data that".
 Is there no sentence after that?

The relationship between Mobile2Static Operation and ::ISO 19111::SC_CRS should replace
 to association(solod line).
-The relationship between Mobile2Static Operation and MobileCRS should replace to 
 association(solod line).
-The relationship between Static2Mobile Operation and ::ISO 19111::SC_CRS should replace to
 association(solod line).
-The relationship between Static2Mobile Operation and MobileCRS should replace to 
 association(solod line).
-In the relationship between Mobile2Static Operation and ::ISO 19111::SC_CRS,
 the association end name "+source" (::ISO 19111::SC_CR side) should replace "+target".
-In the relationship between Static2Mobile Operation and MobileCRS, 
 the association end name "+target" (MobileCRS) should replace "+source".
-The another directed association should added between MobileCRS and Mobile2Mobile Operation.
 (The direction is from Mobile2Mobile Operation to MobileCRS.)
 And the navigability notation(arrow head) and association end name(+source,+target)
 should be added to MobileCRS class side.
-In Mobile2Static Operation class, derived attributes(+source,+target) should added.
-In Static2Mobile Operation class, derived attributes(+source,+target) should added.
-In Mobile2Mobile Operation class, attributes(+source,+target) should replace to
 derived attributes.

-In RoLo Symbolic Position class, attributes(direct,indirect) should replace to derived attributes.


-The navigability notation(arrow head) should be added as follows:
 -SymbolicCRS class side of association between DirectSymbol and SymbolicCRS.
 -DirectSymbol class side of association between DirectSymbol and RoLo Symbolic Position.
 -RoLo Symbol Ref class side of association between DirectSymbol and RoLo Symbolic Ref.
 -DirectSymbol class side of association between DirectSymbol and RoLo Symbolic Ref.
 -DirectSymbol class side of association between DirectSymbol and RoLo Symbolic Position.
 -RoLo Symbol Ref class side of association between RoLo Symbol Ref and RoLo Symbolic Position.


-The association end name should be added as follows:
 -direct : DirectSymbol class side of association between DirectSymbol and RoLo Symbolic Position.
 -indirect : RoLo Symbol Ref class side of association between RoLo Symbol Ref and 
  RoLo Symbolic Position.


-Because the following association is meanings to limit relations defined in superior,
 we should add an explanatory note.
   NumericIdentityCS - NumericIdentityCRS
   SymbolicCS - SymbolicCRS
   IdentityCRS - IdentityDatum

I think that explanation may be added about attributes(direct,indirect)
 in RoLo Symbol Position class.

-In RoLo Error Type Operation class, derived attributes(+source,+target) should added

The constraint {ordered} should be added to attribute(particles) in Particle Set class.
-The multiplicity [0..1] should be added to attribute(errprType) in RoLo Error class.


-The navigability notation(arrow head) should be added as follows:
 -Particle class side of association between Particle Set and Particle.
 -Probability class side of association between Particle and Probability.
 -Weighted Distribution class side of association between Linear Mixture Model 
  and Weighted Distribution.
 -Covariance Matrix class side of association between Gaussian and Covariance Matrix.

-In RoLo Element class, attributes(spec) should replace to attributes.
-In RoLo Architecture class, attributes(spec) should rename to elemSpec, and should replace
 to derived attribute.
-In RoLo Position class, attributes(symbolic,numeric) should replace to derived attributes.
-In Error Element class, attributes(err) should replace to derived attributes.
-In RoLo Data class, attributes(elem) should replace to derived attributes.


-The association end name should be added as follows:
 -symbolic : RoLo Symbolic Position class side of association between RoLo Position and
  RoLo Symbolic Position.
 -numeric : ::ISO_19107::GM_Position class side of association between RoLo Position and
  ::ISO_19107::GM_Position.
 -err : RoLo Error class side of association between Error Element and RoLo Error.
 -elem : RoLo Element class side of association between RoLo Data and RoLo Element.


-The navigability notation(arrow head) should be added as follows:
 -GM_Position class side of association between RoLo Position and GM_Position.
 -RoLo Symbolic Position class side of association between RoLo Position and
  RoLo Symbolic Position.
 -RoLo Position class side of association between Position Element and RoLo Position.
 -RoLo Error class side of association between Position Element and RoLo Error.
 -RoLo Error class side of association between Error Element and RoLo Error.
 -RoLo Element class side of association between RoLo Data and RoLo Element.
 -CS_CoordinateSystem class side of association between RoLo Element Specification
  and CS_CoordinateSystem.
 -SC_CRS class side of association between RoLo Element Specification and SC_CRS.
 -RoLo Error Type class side of association between RoLo Element Specification and RoLo Error Type.
 -RoLo Error Type class side of association between Error Element Specification
  and RoLo Error Type.
 -RoLo Element Specification class side of association between RoLo Architecture
  and RoLo Element Specification.
 -RoLo Architecture class side of association between RoLo Data and RoLo Architecture.


-Because the following association is meanings to limit relations defined in superior,
 we should add an explanatory note.
   Position Element Specification - Position Element
   Error Element Specification - Error Element

-In Position Element Operation class, derived attributes(+source,+target) should added.
-In RoLo Data Operation class, derived attributes(+source,+target) should added.
-The relationship between Position Element Operation and Position Element Specification
 should replace to association(solod line).
-In Position Element Single Operation class, attributes(usesOperation,UsesErrorTypeOperation)
 should replace to derived attribute.
-The navigability notation(arrow head) should be added as follows:
 -CC_SingleOperation class side of association between Position Element Single Operation
  and CC_SingleOperation.
 -RoLo Error Type Operation class side of association between Position Element Single Operation
  and RoLo Error Type Operation.

-Because the following association is meanings to limit relations defined in superior,
 we should add an explanatory note.
   User Defined Data Format - RoLo Architecture

In Table 69 - Common data format type I, the Unit of Orientation is "degree", 
 but the explanation of Orientation is "The unit of this parameter is radians.".
 Which is correct?

-In Table 70 - Common data format type II, the Unit of Position is only "radian".
 It should replace "meter,radian".
-The explanation of Position is "The unit of each value is radian.". 
 It should replace "The unit of r is meter and that of alpha and beta is radian.".
-Table 70 - Common data format type II, the Unit of Orientation is "degree", 
 but the explanation of Orientation is "The unit of this parameter is radians.". 
 Which is correct?

-In RoLo Attribute class, attributes(def,value) should replace to derived attribute.
-In RoLo Attribute ValueList class, attributes(value) should replace to derived attribute.
-In RoLo Attribute Definition Set class, the multiplicity of attribute(attribute)
 should replace to [1..*].


-The navigability notation(arrow head) should be added as follows:
 -one side of self association at RoLo Attribute Set class.
 -one side of self association at RoLo Attribute Definition Set class.
 -RoLo Attribute class side of association between RoLo Attribute Set and RoLo Attribute.
 -RoLo Attribute Definition Set class side of association between RoLo Attribute Set
  and RoLo Attribute Definition Set.
 -RoLo Attribute Definition class side of association between RoLo Attribute Definition Set
  and RoLo Attribute Definition.
 -RoLo Parameter Set class side of association between RoLo Ability and RoLo Parameter Set.
 -RoLo Attribute Definition class side of association between RoLo Attribute
  and RoLo Attribute Definition.
 -RoLo Attribute Value class side of association between RoLo Attribute and RoLo Attribute Value.
 -RoLo Attribute SingleValue class side of association between RoLo Attribute ValueList
  and RoLo Attribute SingleValue.
 -RoLo Attribute Type class side of association between RoLo Attribute Definition
  and RoLo Attribute Type.


-There are associations as follows but there is no attribute in C++ PSM.
 -between Stream Parameter Set and Stream Parameter Definition
 -between Stream Ability and Stream Parameter Definition
 -between Stream Ability and Service Ability
 -between Stream Ability and Service Parameter Definition
 -between Service Parameter Set and Service Parameter Definition

As RoLo ability and its related classes are restructured in issue #13322, these
modifications are not necessary any more.
Disposition: Closed, no change

-In RoLo Streame class, attributes(ability,parameterSet) should replace to derived attribute.
-In RoLo Streame class, the type of augument(ability) at getAbility()
 should replace to "Stream Ability".
-In RoLo Streame class, the type of augument(parameter) at getParameter()
 should replace to "Stream Parameter Set".
-In RoLo Streame class, the type of augument(parameter) at setParameter()
 should replace to "Stream Parameter Set".
-In Stream Parameter Set class, the attribute(dataFormat) should rename to "df".
-In Stream Ability class, the type of attribute(dfList) should replace to "RoLo Data Format".


-The navigability notation(arrow head) should be added as follows:
 -Stream Parameter Set class side of association between RoLo Stream and Stream Parameter Set.
 -StreamType class side of association between Stream Parameter Set and StreamType.
 -StreamType class side of association between Stream Ability and StreamType.
 -Stream Ability class side of association between RoLo Stream and Stream Ability.
 -Service Ability class side of association between RoLo Service and Service Ability.

In Derived From section, "RoLo Parameter" should replace "RoLo Parameter Set".
-In obligation section of attribute df, "M" should replace "O".
-In obligation section of attribute streamType, "M" should replace "O".
-In Condition section, the explanation is "If the RoLo Architecture can be identified by
 the specified data format, the rlaList attribute may not necessary be specified explicitly.",
 what is "rlaList attribute"?

As Stream Parameter and its related classes are restructured in issue #13439,
these modifications are not necessary any more.
Disposition: Closed, no change

In obligation section of attribute dfList, "M" should replace "O".
-In obligation section of streamTypeList, "M" should replace "O".

As Stream Ability and its related classes are restructured in issue #13439, these
modifications are not necessary any more.
Disposition: Closed, no change

-In type section of argument parameter of setParameter(),"Stream Parameter"
 should replace "Stream Parameter Set".
-In type section of argument parameter of getParameter(),"Stream Parameter"
 should replace "Stream Parameter Set".

As Stream Parameter Set and its related classes are restructured in issue
#13439, these modifications are not necessary any more.
Disposition: Closed, no change

-In header definition(P.58), "#include <vector>" should added.
-RoLoAttributeValueSet class(P.58)
 -The class name "RoLoAttributeValueSet" should replace "RoLoAttributeValueList".
 -The type of value "std::set<RoLoAttributeSingleValue>"
  should replace "std::vector<RoLoAttributeSingleValue>".
-RoLoAttributeType(P.59)
 -ISO19111::IO_IdentifiedObject should added as super class.
-UniformGaussian(P.62)
 -The super class "RoLoErrorType" should replace "ErrorDistribution".
-DirectSymbol(P.65)
 -The attribute "dimension:Integer" should be added.
-ErrorElementSpecification(P.69)
 -The attribute "errType:RoLo Error Type" should be added.
-StreamParameterSet(P.72)
 -In super class "RLS::RoLoAbility", "RLS::" should be deleted.
-StreamAbility(P.72)
 -In super class "RLS::RoLoAbility", "RLS::" should be deleted.

-In Table12, "Fixed2Mobile Operation class" should rename "Static2Mobile Operation class".
-In Table18, Derived From section, "CD_Datum [ISO19111]" should replace "CS_SingleCRS [ISO19111]".
-In Table 21, occurrence section of "coordinate", "1" should replace "N ord".
-In Table 36, occurrence section of "values", "1" should replace "N ord".
-In Table 54, occurrence section of "elemSpec", "N" should replace "N ord".
-In Table 55, occurrence section of "elem", "N" should replace "N ord".
-In Table 60, Derived From section, "RoLo Architecture Operation"
 should replace "RoLo Data Operation".
-In Table 60, attribute type section of "childOperation", "RoLo Architecture Operation"
 should replace "RoLo Data Operation".
-In Table 60, description of "childOperation", "Ordered list of RoLo Architecture Operation
 to be appied." should replace "Ordered list of RoLo Data Operation to be applied."
-In Table 61, Derived From section, "RoLo Architecture Operation"
 should replace "RoLo Data Operation".
-In Table 62, Derived From section, "RoLo Architecture Single Operation"
 should replace "RoLo Data Single Operation".
-In Table 63, Derived From section, "RoLo Architecture Single Operation"
 should replace "RoLo Data Single Operation".
-In Table 65, Derived From section, "IO_IdentifiedObject" should replace "RoLo Data Format".
-In Table 125, "ord" of value, "M ord, N" should replace "M , N ord".
-In Table 134, parameter type section of the argument "parameter" in getParameter(),
 "RoLo Parameter" should replace "Stream Parameter Set".
-In Table 134, parameter type section of the argument "parameter" in setParameter(),
 "RoLo Parameter" should replace "Stream Parameter Set".
-In Table 135, parameter type section of the argument "value" in getResult(),
 "RoLo Data Set" should replace "RoLo Data".
-In Table 136, parameter type section of the argument "value" in setResult(),
 "RoLo Data Set" should replace "RoLo Data".

Although the relative/mobile CRS are defined as 'relative' and
'mobile' in Figure 3, operations are defined as 'static' and 'mobile'
in Figure 4. The names are confusing, and shall reflect the
static/dynamic nature of the coordinate systems.

Static2Mobile/Mobile2Static operations defined in Figure 4 are defined
to have SC_CRS as source/target domain. However, as SC_CRS is a base
class for both RelativeCRS and MobileCRS, these operations may take
MobileCRS for both source and target. This is confusing and shall be
well defined.

In 6.3.2 Identity Information, symbolic identity CS/CRS are defined as
'SymolicCS/CRS' where numberic ones are defined as
'NumericIdentityCS/CRS'. Symbolic ID CS/CRS classes shall also be
named in the same manner.

In the RoLo Data class definition (Table 55), there are two attributes
which defines the elements of the target RoLo Architecture: rla (class
RoLo Architecture) and elem (class RoLo Element). This allows
inconsistent specification in the two attributes. Description shall be
added to notice users not to lead any inconsistency

The 'attribute' attribute in RoLo Attribute Set class definition
(Table 127) is inconsistent with the UML diagram (Figure 21).
This shall be defined as 'O' (optional), not 'M' (mandatory).

As RoLo Attribute Set and its related classes are restructured in issue #13322,
these modifications are not necessary any more.
Disposition: Closed, no change

In the RoLo Attribute Set definition (Table 127), there are two
attributes which leads to the elements of the RoLo Attribute
Definition Set: def (class RoLo Attribute Definition Set) and
attribute (class RoLo Attribute). This allows inconsistent
specification in the two attributes. Description shall be added to
notice users not to lead any inconsistency.

As RoLo Attribute Set and its related classes are restructured in issue #13322,
these modifications are not necessary any more.
Disposition: Closed, no change

tino 
The following sentence in the thrid paragraph of 6.3.4 is wrong:
  In such case, the Error Element Specification (derived from RoLo
  Element class) ...


This shall be as following:
  In such case, the Error Element Specification (derived from RoLo
  Element Specification class) ...

The description for Position Element Operation class definition (Table
56), 'RoLo Elements' (twice) shall be replaced to 'Position Elements'.

The 'attribute attribute in RoLo Attribute Definitino Set class
definition (Table 121) is inconsistent with the UML diagram (Figure
21).  This shall be defined as 'O' (optional), not 'M' (mandatory).

Discussion:
As RoLo Attribute Set and its related classes are restructured in issue #13322,
these modifications are not necessary any more.
Disposition: Closed, no change

The RLS Specification FTF Beta1(dtc/2008-07-01) includes Sample C++ Headers(Annex A).
 I think that the C++ Header is PSM model, so we should include it in the specification
as 8.1 C++ PSM

In the revised proposal, especially in Fig. 8 and 9, the class name of RoLo Architecture is confused with the name of RoLo architecutre that consists of the RoLo data specification and RoLo data.

I suggest to substitute the class name of RoLo Architecture to RoLo Data Specification.

 

In Section 6.4.1,  the units of angle in Type I, II and II are not represented consistently .

I suggest to represent the unit of angle for Type I,II with radian, for Type II with degree.

All the parts of the document should be changed appropriately.

 

The desrciption of  position in Table 70 is not commonly used.

Following the ISO 31-11, the description of the position of type II in Table 70 would be better to be [r, ?, f]. 

 

The name of Type II, polar coordination is typically defined as a two dimensional coordinate  system.

The coordinate system would be better to be called as spherical coordinated system that is the three dimensioinal extension of the polar coordinate system

In Table 69, 70, 41, the name of orientation (roll, pitch, yaw) is not relevant to the definition of the orientation that is described below each table.

It would be better to be removed from the tables.

For the Type I, II, II, he definition of the orientation is ambiguous.

More precise definition for the orientation is required (with figures if needed)

 

Before making a decision of including the filter condition as a sub package, we 

have to decide whether the filter condition would be included in the main part or in the Annex part as an option.

At the last meeting in Ottawa, we concluded that the issue of filter condition should be decided after reviewing more real-world examples. (refer robotics/2008-06-14)

I suggest to discuss and decide this issue in December meeting.

Dr. Noda, please show us those examples in December meeting for us to decide this issue.

 

As a result of discussion in Robotics DTF, we had a conclusion that it is better to
make the filter condition to be informative and non-mandatory. However, based
on ‘Policies and Procedures of the OMG Technical Process’ (document number
pp/09-01-02, version 2.8, 21/Jan/2009), we cannot remove significant
functionality from the specification (section 4.4.1.1). Thus, this issue is closed
without change.
Disposition: Closed, no change

* posSpecRef in Error Element (Figure 9/Table 49) shall be a list of
  references to objects


The attribute posSpecRef in Error Element class is now defined as a
list of CharacterString, which is used as a reference to objects of
Position Element class. This shall better be defined as a list of
references.

There are mismatches in the hierarchical structure of Error Type
classes and Error Information classes, which shall correspond to each
other. One solution will be to:
- add ET_ErrorDistribution, derived from 'RoLo Error Type'
- make ET_Gaussian, ET_UniformGaussian, ET_ParticleSet and
ET_MixtureModel to be derived from ET_ErrorDistribution

'public:' is missing in RelativeDatum class definition in
RelativeCRS.hpp (PSM C++ header).

In The Position Element Concatenated Operation class diagram (Figure
10), the childOperation attribute is described to be a reference to a
list of RoLo Element Operation. This does not match its definition in
Table 57, and should be replace to be a reference to a list of
Position Element Operation.

The inStreamAbility and outStreamAbility attributes of Service Ability
class are listed in Table 139 but not in Figure 22.

This is actually not an issue, but Figure 8 "Representation of error
information related to multiple localization data" shall better be
accompanied with an UML object diagram.

There is an activity in ISO TC211 to develop UML diagram of
      filter condition encoding.  So, we should refer it directly
      instead to define our own UML diagram.


    * Filter Condition will be useful specification for various
      application of RLS.  But it domain is slightly different from
      RLS's main target.  In addition, ISO TC211's definition is not
      finalized yet.  So, the specification should be included in the
      annex as an informative.

Particle Set in Error can be defined as a subclass of Linear
      Mixture Model.  In this case each particle is denoted as an
      impulse distribution

* We should have a rule to denote RoLo Data in XML format.  In
      order to do it, we need to have an template of XML schemas for
      the RoLo Data XML format and the mapping rule from RoLo Data
      Specifications.


    * This rule will be a part of annex as informative

* Some applications need to handle unlimited number of CRSs and
      their corresponding structures of RoLo Data Specification. 


      For example, suppose that a human counting application that can
      connect camera systems that are mounted various rooms.  Because
      the origin of CRS used in each camera system is different from
      each other, corresponding RoLo Data Specification is different. 
      It means that the application need to recognize unbounded number
      of RoLo Architectures.  


      In order to avoid such situations, we can utilize hierarchical
      relations among CRSs.  In the case of above example, we define a
      generic CRS, by which a CRS used in each camera system is
      defined a kind of a derived CRS of the generic CRS.  In the same
      time, the human counting application is designed to accept the
      generic CRS and corresponding RoLo architecture.  Then, the
      application can handle each derived CRS and its corresponding
      RoLo architecture.


    * In order to realize such functionality, we should introduce the
      following mechanisms to define relations among CRSs and among
      RoLo architectures. 


    * To define a hierarchical relation between two CRSs, we introduce
      a CRS Hierarchical Relation class.  In the class, baseCRS and
      subCRS are specified.  The baseCRS is a generic CRS and the
      subSRC is a derived CRS.


      Whole relations of CRSs shall form a lattice structure.


    * To define a hierarchical relations between two RoLo Data
      Specifications, we introduce a class for RoLo Data
      Specifications, in which baseSpec and subSpec is specified.  The
      baseSpec is a generic RoLo Data Specification and subSpec is a
      derived RoLo Data Specification.


      Whole relations of RoLo Data Specifications shall form a lattice
      structure.


    * To define a hierarchical relations between two RoLo Element
      Specifications, we introduce a class for RoLo Element
      Specifications, in which baseSpec and subSpec is specified.  The
      baseSpec is a generic RoLo Element Specification and subSpec is
      a derived RoLo Element Specification.


      Whole relations of RoLo Element Specifications shall form a lattice
      structure.

Error Type classes are defined for each Error Information class in Figure 6. However it seems to be unnatural and too complex to define such classes just for discriminating error types. Implementation also is hard.

More natural way would be defining one class that is an enumeration of various error types like the case of RoLo Attribute SingleValue in Figure 21.

 

In Table 22, 'Point' attribute of RoLo SymbolRef should be renamed by 'point' for namning consistency.

In Table 36 (Matrix) the obligation of 'values' attribute is mandatory but it is represented as optional in Figure 7. Which one is correct?

In Table 62, the type of 'usesOperation' attribute of RoLo Data Transformation should be "Position Element Operation".

In Figure 21 (RoLo Ability and RoLo Parameter Set), the aggregation association between RoLo Parameter Set and RoLo Parameter Definition is not fully specified. If it is for derived 'def' attribute, we should add association end name in Figure 21 and an explanatory note to limit the value of derived attribute in Table 128 (RoLo Parameter Set).

As RoLo ability and its related classes are restructured in issue #13322, these
modifications are not necessary any more.
Disposition: Closed no change

The 'choice' attribute of RoLo Attribute Definition class (Table 120) can only represent a list of discrete values. In case of ranged attributes that have minimum and maximum value, it cannot be well expressed.

One possible resolution is to introduce a new class, RoLo Attribute RangeValue, which is derived from RoLo Attribute Value and has 'minValue' and 'maxValue' attributes of type of RoLo Attribute SingleValue.         

 

Conformance criteria described in chapter 2 is too simple and too
strict. Shall be described in more detail.

Reference described in chapter 3 is not enough, and shall be
added. Non-normative references may also be helpful.

There are certainly some terms and definitions required for this
specification.

Chapter 5 "Symbol" shall be described, especially for the data format
section. 

Not sure whether this section is necessary, but if so, some more
organizations shall be added here.

Some more people shall be added here.

There are some simple typos in "6.3 Background." For example, the
phrase 'wit this specification' at the end of page 6 shall be 'with
this specification.'
Also, for the purpose of this specification, it is better to describe
explicitly that this specification can be applied to fields other than
robotics, such as GIS or LBS.

The paragraph beginning with 'In order to fulfill the requirements...'
in 6.3 needs to be updated

In this specification, the CS_CoordinateSystem class from ISO19111 is
used in a rather special manner than its original intention, such as
the assumption for using it in n-dimensional spaces (where n >
3) or using axis definitions in a more flexible manner. Although this
does not violate the original ISO specification, it is better to have
some notes.

The description for 'rla' attribute in RelativeDatum class (Table 6)
is somewhat ambiguious. The second sentence 'If the base attribute
contains structural information, ' shall be modified as following: 'If
the base attribute contains structural information, or if the
coordinate reference system in target holds no relation with other
coordinate reference systems,'.

'inStream' attribute in MobileDatum class shall be an object, not n
  reference to an object.


There seems to be no reason to make the 'inStream' attribute to be a
reference. 

'numDists' attribute in Lineare Mixure Model class may be unnecessary 

The 'numDists' may not be necessary, as this value can be obtained
from the 'dists' attribute (which is a list).

'Of minOccurence...' shall be modified to be 'If minOccurence...'.

As RoLo Attribute Definition class has been revised in #13322, no revision is
made here.
Disposition: Closed, no change

The RoLo Service class may be modified not to inherit OutStream
class, as to clarify its functionality. In order for this change, the
following modification are required: 1. Change description at the
beginning of 7.5 Service Interface, 2. UML diagram fix, and 3. add
some attributes that were inherited from OutStream class. (Originally
proposed by Mr. Han, ETRI)

The phrase 'Service Parameter class' in the Service Ability class
description shall be 'Service Parameter Definition class'. UML diagram
shall be fixed, and also a subset note shall be added to the relation
between Service Ability class and Service Parameter Definition class
in the diagram.

As ServiceAbility class has been revised by issue #13322, this issue is closed
without change.
Disposition: Closed, no change

As class names with blanks are not allowed in most programming
languages (or XML defnitions), different class names are used in PIM
and PSM. This should be fixed. One way is to remove blanks from PIM
class names.

Some classes have 'RoLo' prefix in their names, and others do
not. These namings shall be modified to follow some rule.

See issue 13441 for disposition

The argument types for 'setParameter' and 'getParameter' methods in
RoLo Service class shall be 'Service Parameter Set' class, not
'Service Parameter' class.

This issue is closed without change due to the changes in #13439.
Disposition: Closed, no change

The RLS specification refers to some other specifications.
These references should be added. For example,
  *[UML] Unified Modeling Language, Superstructure Specification version 2.1.2
    http://www.omg.org/technology/documents/formal/uml.htm
  *[XML] .....

- (Fig7/Tbl36) Reference to ISO19103 missing for Matrix::values
- (Fig7) Matrix.values shall be drawn as an composition to ISO19103::Number
- (Fig3) RelativeDatum.rla is not described as optional
- (Fig3) Description of RelativeDatum.base is hard to understand. Please clarify.
- (Fig5) RoLo Symbol Ref.point and DirectSymbol.coordinateReferenceSystem shall be described as association name. Also these association shall be arrowed.
- (Fig10) Position Element Concatenated Operation.childOperation, RoLo Data Concatenated Operation.childOperation and RoLo Data Transformation.usesOperation shall be described as derived attributes.
- (Fig11) association between User Defined Data Format and RoLo Architecture shall be drawn as an arrowed association between Specific Data Format and RoLo Architecture
- (Tbl33) Description shall say this class is abstract
- (Tbl35) Description shall say this class is abstract
- (Tbl35) Delete unnecessary 'Attribute' row from table
- (Tbl37) Add note indicating that covariance matrix need to be a square matrix
- (Tbl39) Uniform Gaussian, from its meaning, shall be a child class of Gaussian class. Thus, its 'stddev' attribute is unnecessary and 'covariance' attribute in Gaussian class shall be used. However, restriction shall be noted that this 'covariance' attribute can only be a matrix where row/col dimensions are limited to 1
- (Tbl43) reference to ISO specification missing in 'Derived From'
- (Fig7/Tbl43) For Weighted Distribution class, reference to ISO specification missing for type name (Probability) of attribute weight
- (Fig7) Weighted Distribution class's 'weight' shall be described as composition
- (Fig7,Tbl45) 'dists' attribute for Mixture of Gaussian class shall be restricted to Gaussian class, from its meaning
- Section number "6.2" in the sentence starting as "Note that derived attributes" in 7.1.1 is wrong; should be "7.2"
- (Tbl8) The word "Polar" shall be "polar" in the description line
- (Tbl46) Reference to ISO specification missing for typename of 'numeric' attribute
- (Fig9) 'elem' attribute in RoLo Data class shall be described as composition
- (Tbl55) Typo in description for 'elem' attribute: Ordered list for the... -> Ordered list of the...
- (Tbl36) Describe that dimensions of matrix shall always be 1 or more than 1; that is, matrix will never be 0-dimensional
- Information on Submitters and Submitting Organizations shall be added
- (Fig5,Tbl21) 'dimension' attribute for DirectSymbol class is redundunt; it can be obtained from the list 'coordinate'.
- (Fig22,Tbl134) The names of setParameter/getParameter methods are strange. It is the parameter values that is to be set/get, not the parameter itself. It shall be renamed as setParameterValue/getParameterValue
- (Fig22,Tbl135) The name 'getResult' in OutStream class is not consistent with the 'setData' method in InStream class. This shall be changed to 'getData'
- Attribute names are inconsistent throughout the specification. Some are plural and some are not plural, even if it denote a list of values. Some are abbreviated and some are not. This inconsistency shall be fixed.

(7.4.1) Timestamp for common data types are described as 'POSIX time' but it is not clear which type shall be actually used

(Annex A) Mapping between PIM and C++ PSM is not clear

(7.5) In the filter condition section, an extention to RoLo Service class is described which enables RoLo Services to specify filter conditions. However, this is not a good way to implement, and will lead in lack of interoperabiility. Instead, it is much better to make it so that conditions can be specified through some parameters

7.5) Filter condition requires naming of RoLo data elements. However, the naming rules are not clear.

Fig3,Tbl9,Fig22,Tbl134,Tbl140) Mobile Datum class, RoLo Stream class and RoLo Service class holds public attributs and at the same time provide methods for obtaining the value of the same public attributes. This is redundunt and is losing flexibility of dynamically creating the returned values

Fig5,Fig9) RoLo Symbolic Position class and RoLo Position class are specified to be 'union' but it is better to leave them unspecified. 'Union' is hard to implement for some programming language

(Fig7) Matrix class is specified as "DataType" but this is unnecessary

Tbl119-Tbl129) A set of class related to attribute/parameter/attribute definition is defined, but usage of these classes are not clear. For example, difference between 'parameter' ad 'attribute' is not clear, or how 'attribute definition' classes are related with 'attribute' classes is not clear. Please clarify. Also, there seems to be too many classes of simliar meanings. 

Tbl124) Specifying RoLo Attribute Singlevalue class as an enumeration is hard to implement for some programming languages. It also lack extendability for new data types. It is better to specify it as template class.

7.6) RoLo service is described to have only one output stream, but this is sometimes too difficult to use. It should allow multiple output streams, such as those of server daemons, of the same nature.

Increasing the number of output streams that a RoLo service can handle may
violate the FTF rule. Thus, we will not make changes for this issue. However, the
resolution for issue 13439 may allow RoLo services to own multiple output
streams.
Disposition: Closed, no change

(Tbl135/Tbl136) The 'connect' method for initiating service usage is defined for 'stream' classes. However, in most existing systems or languages, connection initiation is performed toward services, and not toward streams. This should be moved as a method for RoLo Service

(Tbl135/Tbl136) The 'connect' methods lacks the facility to let the targetting module to know about which module is making the connection. This knowledge is required for some methods such as 'getConnectedStream' method in RoLo Stream class. Some means shall be provided to make this specification independent to underlying middleware

Tbl134) The behavior of setParameter method in RoLo Stream class is unclear. When this method is specified an unknown parameter, it shall return some error code. But which type of error code is returned is not described. Please clarify

Tbl130) Two types of data passing mode specified in StreamType enumeration is not clear. It is currently defined to be relative to the stream in concern, but shall be defined by which side of data flow is holding the trigger for data passing.

Tbl130,Tbl136) The 'setData' method in InStream class may be used for 'PUSH' type data passing. However, it is quite common that input side streams can not process all the data received. In such case, some flow control mechanism is required. Such mechanism is required for practical use. This should be defined in the specification, not depending on the middleware's ability of flow control.

As in most C++ implementations, it is better if methods will return
the return codes (Returncode_t) as exceptions.

The following associations shall be composition and shall have subset
specification. 
  RoLo Stream - Stream Ability
  RoLo Service - Service Ability

The parent class for RelativeCRS is described as SC_CRS but is
actually SC_EngineeringCRS.