Obligation of AttributeSet::attrs & AttributeSet::def seems not correct (attrs: M, def: O ?)

As pointed out, Interface::AttributeSet.attrs shall be marked as optional in the UML
diagram. Moreover, AttributeSet.def is not necessary, as AttributeDefinition-s can be
accessed through each AttributeBase contained in the AtributeSet instance. Thus, we will
remove the AttributeDefinitionSet class and AttributeSet.def.

First, it is hard to access the target Parameter from ParameterValueBase. Second, it is not clear whether we should provide a pointer to a real Parameter instance for ParameterValue::param attribute or use a clone. If clone, we should deallocate the memory (who do?) If not clone, we should not deallocate the memory. There is a possibility that the values of ParameterValue::val and ParameterValue::param.val are inconsistent. How about ParamterValue class to refer to the ID of Parameter instance not the instance itself?

Whether to use a pointer or cloned instance is an implementation issue and will
not be discussed here. As suggested, one way of implementation is to refer to
some ID of Parameter instance, such as the one inherited from
ISO19111::IO_IdentifiedObject. See issue 16201 for discussion on the
referencing system.
As for the two ‘val’ attributes, the actual values for each Attribute (or Parameter)
instance is held by Attribute.val. ParameterValueBase and inherited class
instances are used for passing the values to be set, typically through
InterfaceBase::setParameterValues() or to obtain the current values through
InterfaceBase::getParameterValues(). As this was not clearly stated in the
specification, we will add some more description.

InStream & OutStream are just conceptually different in usage but physically the same. The separation makes the implementation difficult. Instream may be redundant, and OutStream also requires setData().

No Data Available

In Figure 7.10 - RoLo Data Operation, the relation between DataMappingOperation class and ElementSpecification class is defined as aggregation. However, considering the strength of relation between the two classes, directed association is much suitable.

Change the relation between ElementSpecification and DataMappingOperation.

Auto configuration between RoLo Service modules across the network is not supported currently. Return value of getAbility: variable data length, data type, ...How to interpret the result without sharing of memory address? We need to define how to serialize data.

No Data Available

CRS is very important in RLS, but the usage is not clearly described in the Spec. Just referred ISO. Especially, AxisDirection is confusing. Inconsistent implementation may be possible among developers

No Data Available

We can access parameter values in two ways: InterfaceBase::getAbility and InterfaceBase::getParameterValues. InterfaceBase::ability can be StreamAbility or ServiceAbility and they have inherited attribute (attrs) from AttributeSet. They also have their own class-specific parameters (frequency, expectedLatency, ... ). However, there only is InterfaceBase::getAbility. We need InterfaceBase::setAbility to initialize Service or Stream. It is not clear what the configurable parameters of InterfaceBase::get/setParameterValues are. Implementation of InterfaceBase::get/setParameterValues is very complex and confusing. Class-specific parameters also are attribute, but handled separately from 'attrs' of AttributeSet.

No Data Available

As for Service::connect() method, difference of two connect() methods are not clearly described, and developers can be very confused. The notations IN service and OUT service is confusing. Given a relation A->B, which one is IN service? Receiver(IN) / Sender(OUT) would be more clear conceptually.

As described, the difference of the two connect() methods are in which side
initiates the connection. The notation ‘receiver’ and ‘sender’ is, as suggested,
much clear. Thus, change ‘IN service’ as ‘RECEIVER service’ and ‘OUT service’
as ‘SENDER service’.

In Figure 7.19 - RoLo Service and in Table 7.91 - StreamAbility class, the 'frequency' attribute of StreamAbility is marked as optional. However, it is not clear in what way the module behaves when the frequency attribute is omitted. Also, as for the dataSpec attribute, don't-care shall be defined for dataFormat and frequency attributes to indicate that no specific value is defined.

No Data Available

In C++ implementation, the element types should be a pointer or reference to enable homomorphism. It means that we need dynamic memory allocation/deallocation for data passing, making the implementation very difficult, such as for identifying real instance type or for copying data. C++ PSM part of RLS Spec. should be corrected into pointer type not to make the developers confusing.

No Data Available

In Figure 7.5 - RoLo Error Type and in Table 7.28 - ErrorTypeOperation class, only 'source' (ErrorType) and 'target' (ErrorType) attributes are defined. However, these attributes are parameters for determining the type of conversion operation, and the actual Element-s to be converted shall as well be specified.

No Data Available

We defined common data format but not specified how to identify them.

No Data Available

In table 7.80 - Parameter class, the type of 'isConfigurable' attribute is denoted as 'Bool' but this shall be 'Boolean'.

Modify the type of isConfigurable attribute in Parameter class definition as
“Boolean”.

The note in Table 7.35 - UniformGaussian class says "Dimensions of the cov attribute derived from class Gaussian shall all be equal to 1. That is, nRow = nCol = 1." However, as a covariance matrix is diagonal from its definition, the number of rows/columns shall be more than one (starting from two).

No Data Available

In Figure 7.6 - RoLo Error, multiplicity of Architecture: WeightedModel.weight is fixed to "1". However, in some cases, such as representing result of simple Monte-Carlo sampling, weights may be unnecessary (equal to 1/N), so the multiplicity shall better be specified as optional ("0..1").

See issue 16179 for disposition

The use of 'base' and 'dataSpec' attribute in Architecture::StaticRelativeCRS is not clear.

No Data Available

Although examples of XML description is provided in Annex A, an formal
specification such as XML schema is also necessary for constructing a
parser.

Besides XML examples, Annex A provides XML schema definitions. However, the
definition is not complete. Thus, revise the XML schema definition in Annex A.

Argument type of InterfaceBase::get/setParameterValues is 'set' in PIM but 'list' in PSM. It may cause the developers confusing.

In C++ PSM, we found several points of similar inconsistency:

• std::vector is used to denote ordered list in some definitions and std::list is used
  for other definitions
• ordered and non-ordered list sometimes does not match the definition in PIM
  In order to clearly represent the PIM, the following rule will be applied for PIM =
  C++ PSM mapping:
• non-ordered list will be mapped to std::set
• ordered list will be mapped to std::vector
  Based on these rules, the followings points will be modified in C++ PSM:
• Modify InterfaceBase::getParameterValues() and setParameterValues()
  methods to use std::set
• Modify SetParameter class to bind to::std::set<T> for template parameter
• Modify SetParameter.attrs attribute to use std::vector
• Modify ServiceAbility.inStreamAbilities attribute to use std::set
• Modify Service.getChild () method to use std::vector
• Modify Service.inStreams and outStreams attributes to use std::vector
  In addition, we found that there are some inconsistency between the table
  description and UML, and these will be fixed as following:
• In Service class, based on the text description, the attributes inStreams and
  outStreams will be marked as “N ord” in the table and will be marked as
  “ordered” in the UML diagram

In C++ PSM, Service class should be derived from InterfaceBase class, not from OutStream.

Modify Service class definition in Service.hpp to be inherited from InterfaceBase
class.

StreamAbility::dataFormat has its own DataSpecification. Difference of these two DataSpecifications is not clear. is it just a redundant duplication?

The two attributes, dataFormat (which is a set of DataFormat::DataFormat
instances) and dataSpec (which is a set of Architecture::DataSpecification) are
necessary, as these indicate the possible choices that a certain stream can
handle. Users of this stream will choose the appropriate data format or data
specification from the set of available choices. As pointed out, this is not clear in
the current description, so we will add some more description

Description on Architecture::Abilty and inherited classes are
confusing and difficult to use.

See issue 16206 for disposition

When identities are to be limited to finite set of values, such as a set of predefined symbols or discrete numerical values, how can this be represented?

Define a new class Architecture::SetCoordinateSystemAxis for representing axis
with finite set of values. In addition, for convenience, add two frequently used
axes StringSetCoordinateSystemAxis and IntegerSetCoordinateAxis.

The following description on symbolic extension may be insufficient (in P.19, third paragraph):
"The actual coordinate value holding structure in GIS standard [ISO19107] only allows numeric values as coordinate value elements. Thus, similar structures in use with symbolic values are also defined."

No Data Available

In Figure 7.1 - Relative and Mobile coordinate reference system, Architecture::InStream and Architecture::MobileDatum are related as composition. However, as Architecture::InStreamcan exist by itself, the relation shall be weaker. Possibly modify Architecture::MobileDatum to use InStream (directed assotiation).

No Data Available

In Figure 7.10 - RoLo Architecture, Position class is defined to hold both symbolic and numeric values. While Symbolic Position class for holding symbolic values is derived from IO_IdentifiedObjectBase [ISO19111], numeric values are held by GM_Position [ISO19111] class which is not derived from IO_IdentifiedObject. Thus there is an asymmetry in the two definitions.

See issue 16173 for disposition

In Figure7.3-Identity Information, classes Architecture::DirectSymbol and Architecture::SymbolRef for representing symbolic values are defined as subclasses of ISO19111::IO_IdentifiedObjectBase. However, ISO19107::DirectPosition, ISO19107::GM_PointRef, which are the counterparts for numeric values are defined as 'DataType' and are not subclass of ISO19111::IO_IdentifiedObjectBase, thus leading to inconsistent definitions.
Also, Architecture::Position class (Figure7.8-RoLo Architecture) is defined to be able to hold either a symbolic value (Architecture::SymbolicPosition) or a numeric value (ISO19107::GM_Position). However, while Architecture::SymbolicPosition inherits ISO19111::IO_IdentifiedObjectBase, ISO19107::GM_Position does not, thus showing inconsistency.

As Architecture::Position class is inherited from ISO19111::IO_IdentifiedObject,
there shall be small requirements for these classes to hold identity information by
itself. Modify Architecture::DirectSymbol, Architecture::SymbolRef and
Architecture::SymbolicPosition definitions as not to be subclass of
IO_IdentifiedObjectBase.

In Figure 7.2 - Mobile CRS operations, Architecture::MobileOperation is defined as a subclass of ISO19111::CC_Transformation. However, it may be better to define as a subclass of much general ISO19111::CC_SingleOperation. (Note: ISO19111::CC_CoordinateOperation is not appropriate as a parent class as if we did so, Architecture::MobileOperation cannot be elements of ISO19111::CC_ConcatenatedOperation instances).

No Data Available

Explicit CRS definition for pose information is necessary. Especially, the relation between pose CRS and position CRS and its semantics shall be defined

In ISO 19111 which RLS is based on, relation between CRSs is defined by using
datums and transformations. In this sense, in order to represent pose information,
we need to define a new datum. However, we found that generally this is not
appropriate as identifying pose is tightly related to its associated position. In the
original idea of CSs and CRSs in ISO 19111, CSs implicitly hold transformations
that can in most cases be identified trivially. However, when extending this to
pose, the necessary transformation becomes not so trivial and thus a much
explicit mean for specifying the associated transformation, in combination with
‘position’ transformation, becomes necessary. Moreover, it is only a special case
that position and pose information (or transformations) are mathematically
independent, i.e., where transformations for position and pose can be defined
separately. Therefore, position and pose information shall be represented in
combination inseparable from each other. One way is to represent position/pose
as a generalized position which is a set of parameters for a transformation that
defines a mapping from the base CRS to the resulting position/pose. In this
sense, what is called a CS or CRS shall be represented as a transformation ,and
coordinate values which we normally call ‘position’ are parameters for the
transformation. (for detailed discussion, see [Noda2010])
[Noda2010] Itsuki Noda, Shuichi Nishio, Takashi Tsubouchi, Takeshi
Sakamoto and Satoshi Tadokoro, "Mathematical Framework for Localization
Information Coordinate Reference System for Robotics", in Proc. of Int.
Workshop on Standards and Common Platform for Robotics 2010 (SCPR
2010), 2010.
This notion is mathematically much rigid. However, it requires complete
reconstruction of the ISO 19111 which RLS is based on. As this is not something
to be discussed here, here we propose a much modest modifications. In the
future, this shall be discussed in ISO/TC 211.
Followings are the modified points: - Add non-normative reference

• Add background description (section 7.3 – Architecture Package)
• Add two classes (PoseType and PositionPoseCRS) in Architecture Package
• Define frequently used pose types
• Modify section 7.4.1 – Common Data Format to use the defined pose types and
  remove figures/descriptions that also appear in previous description
• Modify C++ PSM accordingly

In Figure 7.6 - RoLo Error, multiplicity of Architecture::WeightedModel for Architecture::LinearMixtureModel is defined as "1..". However, as there may be cases that no model exists, it is better to define it as "0..".

Concerning also issue 16189 where the multiplicity of weight attribute in
Architecture::WeightedModel is raised, we perform the following modifications:
1) Define a new Architecture::Model class which is derived from
Architecture::PositionElement. Although no attributes or methods added here,
this class is for representing probability distributions or models, with a position
in the space and error distribution.
2) Modify Architecture::WeightedModel class to be derived from
Architecture::Model class and remove the posElem attribute (this is not
necessary any more due to its parent class-). Thus, only models with weights
are represented by the WeightedModel class and thus the ‘weight’ attribute is
left as mandatory.
3) Modify Architecture::LinearMixtureModel class to aggregate
Architecture::Model instances instead of Architecture::WeightedModel, so that
when the weight in the models shall not be specified. the Model class
instance shall be used. At the same time, modify the multiplicity of the
‘models’ attribute as “0..*.” Also, add some description in the definition of
LinearMixtureModel class to indicate how the aggregation of non-weighted
models shall be interpreted.

ISO19111::CS_PolarCS is to be used for representing polar coordinate systems. However, no specific axis is defined for this coordinate system.

No Data Available

CRS for symbolic systems are defined in Figure 7.3 - Identity Information as extension to ISO19111. Operations specific to these CS/CRS are missing.

No Data Available

In Figure 7.10- RoLo Data Operation, no operation is defined for Architecture ::ErrorElement , except Architecture ::DataMappingOperation. Some operation for transforming error information, as Architecture ::PositionElementOperation for Architecture ::PositionElement, is necessary.

No Data Available

In Figure 7.8 - RoLo Error, Architecture::Matrix is defined as a subclass of IO_IdentifiedObjectBase. However, as it is quite unlikely that instances of this class requires to be identified, it is better to define it as a DataType.

Change Architecture::Matrix to a DataType and remove inheritance from
IO_IdentifiedObjectBase [ISO19111].

Classes and objects for using don't' cares are defined in Figure 7.9 - Don't-care classes and objects. However, it may be better to define the subclasses of Architecture::DontCare as DataType, as instances of these classes will be treated as constants

No Data Available

The Interface::StreamAbility instance obtainable from Interface::Stream denotes the ability of each Interface::Stream instance. However, there is no method for obtaining how each instance is configured. Such a method is necessary.

No Data Available