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.

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.

Separate XMI from the main RLS specification document

(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

See issue 13439 for disposition

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

Add the following sentence in "Description" of Table 23:
This class is used as a data holder for accessing symbolic information transparently,
whether it is directly held or indirectly referenced.

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

withdrawn by submitter

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

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.

Add some additional description to relevant tables for showing limitation that
‘static’ CRS shall not be an instance of DynamicRelativeCRS or inherited classes

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.

Introduce new classes (RelativeCRS, RelativeDatum, DynamicRelativeCRS and
DynamicRelativeDatum) to reflect the static/dynamic nature of the relative
coordinate systems separately. RelativeCRS is renamed as StaticRelativeCRS,
and names of related classes are changed in a similar manner. Make MobileCRS
to be derived from DynamicRelativeCRS.
Based on this change, Mobile CRS is a special case of Relative CRS. Therefore,
change the title of section 7.3.1 Relative and Mobile Coordinate Reference
Systems to be 'Relative Coordinate Reference Systems' to avoid confusion.

-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".

Correct the typos according to the suggestions in summary of this issue.
However, the typos in Table 125 and 134 does not exist any more due to
changes by issue 13322. Therefore, we simply discard these two items.

-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.

All suggestions except the one for ErrorElementSpecification is now unnecessary
due to changes made in other issues.

-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

No Data Available

-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?

See issue 13120 for disposition

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.

No Data Available

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 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.

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

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 order to make the naming consistent, rename SymbolicCS to
SymbolicIdentityCS and SymbolicCRS to SymbolicIdentityCRS.

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

Place additional sentences to ‘elem’ attribute description for showing that
consistency is required.

-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".

No Data Available

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

No Data Available

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"?

No Data Available

• (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.

Fix typos based on the suggestions

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.

In addition to the item pointed out in the summary, some class names have the
¡¥RoLo¡¦ prefix and some does not (issue 13442). In order to resolve these
inconsistencies, the following changes are performed:
„O Remove blanks from PIM class names
„O Remove 'RoLo' prefix from PIM and PSM class names
„O Instead, use global namespace 'RoLo' in place of 'RLS'. As most class
definitions belong to some packages (from issue 12916), two namespaces
will be used for class definitions.
For example, ¡§RoLo Element Specification¡¨ class will be renamed as
¡§ElementSpecification¡¨ or ¡§::RoLo::Architecture::ElementSpecification¡¨ in full
resolution.
However, this change makes descriptions in natural language harder to read. To
make sentences simple, we follow the resolution from #13116 such that
whenever class names are used to indicate its instances, the names are written
in small letters in divided forms with a ¡¥RoLo¡¦ prefix. For example, ¡§xxx is a list of
references to PositionElement class instances¡¨ are rewritten as ¡§xxx is a list of
reference to RoLo position elements.¡¦
There also exist inconsistencies in attribute names (from issue 13998). To
reduce this inconsistency, we will modify attribute names based on the following
rules:
¡E Shorten the attribute names whenever it is possible, but keep it long when
it is not easy to infer the original name. Use the same attribute names across the specification whenever they
indicates the same meanings.
• Make attribute name to be plural when multiplicity of the attribute is able to
be more than 1.
For clarification, we will enclose the names of attributes and methods with a pair
of single quotation marks whenever they appear in natural language sentences.

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.

No Data Available

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

Describe how C++ PSM was mapped from PIM

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

See issue 13120 for disposition

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

Make the attributes as protected

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

See issue 13184 for disposition

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

Stop using ‘union’ as suggested in the summary, For the C++ PSM, as we found
that some compilers are unable to treat ‘union’ with elements that owns
constructors, we will also stop using union and make the elements as pointers.
Implementers need to be aware that only one of the elements shall be effective.

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] .....

See issue 13427 for disposition

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

No Data Available

(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

See issue 13184 for disposition

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

Remove the stereotype as suggested

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

No Data Available

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

Delete Particle class and reorganize classes in Figure 7 to reduce the hierarchy
of Error classes. Also add some description for improving understandability.

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.

As described in issue 13122, Filter Condition cannot be moved to be an
informative part for now, and thus will remain in its original position as mandatory.
However, as an identical ISO standard which can be used for RoLo service is
under process, descriptions will be modified to use the ongoing ISO draft. Here,
we modify the interface for treating filter conditions in Robotic Localization
Service. In the beta1 specification, section for filter condition (7.5) defined an
additional method for RoLo service class to treat filter condition data. As pointed
out by issue 14001, this is not a good way from the viewpoint of interoperability.
Thus, we define a much simple method that treats filter condition as a parameter
defined in ability description for RoLo streams. This allows users to check
whether filter condition functionality is supported or not and provides an easy
mean to specify conditions.
In addition, as the new filtering functionality based on ISO standard requires XML
notation of RoLo data (also from issue 13186) and naming rules (from issue
14002), we define two informative annexes, XML-PSM and naming rules. With
this addition, some description about what is given as annex is also added in
Section 1 “Scope”.

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

Add further description showing the conformance conditions.

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.

solution suggested in the summary is sufficient for this issue. But similar
issues may rise if we kept on using the current definition of RoLo Attribute
SingleValue class defined as an enumeration of types which is not extendable by
users. Thus, in order to make the RoLo Attribute structures more extendable and
flexible, we restructure these classes to use type templates. In addition, some
more sentences are added to clarify how RoLo attribute and related structures
are to be used.
Also from issue 14006, there are too many classes of similar functionality.
Especially, usage of RoLo Attribute Definition Set was unclear and distinction
between RoLo Attribute and RoLo Parameter (Set) was not clear. Thus, the
following reorganization of class structure is proposed:

• Remove the RoLo Attribute SingleValue, RoLo Attribute Value, RoLo
  Attribute ValueList, RoLo Attribute Type classes that were used to represent
  variations of type/value pair. InStread, Make RoLo Attribute class to be a
  template class. By this change, RoLo Attribute can be used for any time that
  is required for attributes.
• Separate ‘attribute’ and ‘parameter’ explicitly, and describe their differences.
  Here, attributes are ‘constant’ parameters that users cannot change.
  Parameters are user-changeable attributes. As requested by summary, we
  will prepare several template types for the datatype of parameter. This is for
  convenience, and users can always extend this to any types on demand. Simplify the attribute set/attribute definition set class structures for clarity.
  Some attributes (such as min/maxOccurence in RoLo Attribute Definition) are
  not necessary any more due to the introduction of templates (users can
  always define types with these occurrence limits).

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.

Instead of the way suggested in the summary, we decided to use only a single
class for describing RoLo error types and use hierarchy of RoLo error type
instances to represent the relationships instead of the class hierarchy in the
original specification. By this change, we can decrease the complexity of defining
classes that is never instantiated while preserving the original functionality and
extendibility.

• 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.

Instead of introducing a new class to represent hierarchical relationship among
instances, use the don’t-care functionality in the original specification. However,
as there were not enough description in the original specification and also as
there were some errors, do some reorganization to clarify this.

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

Modify Table 62 as described in the summary. Also modify the description for this
attribute to fit this change.

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

The obligation of 'values' attribute is mandatory. Therefore, fix Figure 7 to make
'values' attribute to be mandatory

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.

For better understanding of the specification, add an non-mandatory UML object
diagram into Figure 8 so that the original figure is accompanied with the UML
object diagram.

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

See issue 13322 for disposition

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.

Correct the typo as suggested in the summary

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).

No Data Available

• 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

See issue 13184 for disposition

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

Correct the typo

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,'.

Modify the description for 'rla' attribute according to the suggestion in the
summary.

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.

Add some description which clarifies the difference between the usage in this
specification and the implicit assumption made in the ISO 19111 specification.

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.

Correct the typo and add some description in section 6.3.

Some more people shall be added here.

Add names to be acknowledged.

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

Add necessary references. Also, split chapter 3 to include both normative and
non-normative references.

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)

In the beta1 specification, the RoLo service class which denotes the service
interface for Robotic Localization Service was described to be inherited from
OutStream class which denotes data output stream. This issue points out that
although from the point of functionality this is sufficient, from the meaning of the
classes this is somewhat misleading. Thus, we decided to change the structure
of RoLo service class so that it will not be inherited from OutStream, but instead
will contain OutStream instances as well as InStream instances.
Based on the proposed solution, we made a reconstruction of RoLo Service
class and related classes. Based on this change, some additional description is
also added for clarity.

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

Add another section describing the organizations which submitted the original
specification. Also, from issue 13998, add submitter information

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

No Data Available

'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).

Delete 'numDists' attribute from Lineare Mixure Model class.

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

Add necessary symbol descriptions

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

Add necessary definitions on terms used in this specification

'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.

Although the ‘Description’ part of MobileDatum explicitly says that ‘inStream’
attribute is an instance, it is described as a reference in the description of the
attribute. Fix this inconsistency and modify ‘inStream’ attribute in MobileDatum as
non-reference.

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

See issue 12916 for disposition

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.

Add non-mandatory sequence diagram and accompanying description at the last
part of section 7.5, in order to show typical RoLo service usage.

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.

Modify Figure 2 as follows:
¡V Divide the RoLo package into four sub packages of Architecture
package, DataFormat package, FilterCondition package and Interface
package.
¡V Delete original dependency relationships between RLS and GIS
standards and add the following dependency relationships in the
diagram:
ƒÞ from Architecture package to ISO 19107
ƒÞ from Architecture package to ISO 19103
ƒÞ from Interface package to ISO 19103
ƒÞ from Interface package to ISO 19115
ƒÞ from DataFormat package to Architecture package
ƒÞ from Interface package to Architecture package
ƒÞ from Architecture package to Interface package
ƒÞ from RoLo package to ISO 19111
ƒÞ from FilterCondition package to Interface package FilterCondition package to ISO 19142
ƒÞ from FilterCondition package to ISO 19143
Add the following sentences(package descriptions) at the beginning of section
7 (Platform Independent Model):
The PIM consists of four parts:
1. Architecture package
The architecture package defines a new framework for representing location informatio
n required in the field of robotics. See section 7.3.
2. DataFormat package
The data format package defines how the defined data is represented for exchange amo
ngst RoLo modules. See section 7.4.
3. FilterCondition package
The filter condition package defines methods for filtering localization results. See secti
on 7.5.
4. Interface package
The interface package defines an API for data passing and configuration of RoLo modu
les. See section 7.6.
Change the following section titles as package names:
¡V Change the title of section 7.3 Representing Robotic Localization
Results into 'Architecture Package'.
¡V Change the title of section 7.4 Data Formats into 'DataFormat Package'.
¡V Change the title of section 7.5 Filter Condition into ¡¥FilterCondition
Package¡¦.
¡V Change the title of section 7.6 Service Interface into 'Interface Package'.
Add package name to following items:

• MobileDatum class (Table 9 and Figure 3): change type name of
  ¡¥inStream¡¦ attribute and ¡¥inStream¡¦ argument of ¡¥getInStream¡¦ method to
  RoLo::Interface::InStream
• SpecificDataFormat class (Table66): change type name of ¡¥rla¡¦ attribute
  to RoLo::Architecture::DataSpecification.
• StreamAbility class (Table 124 and Figure 22): change type names of
  ¡¥rlaList¡¦ and ¡¥dfList¡¦ attributes to RoLo::Architecture::Data and
  RoLo::DataFormat::DataFormat respectively. OutStream class (Table 135 and Figure 22): change type name of
  ‘getResult’ method’s argument ‘value’ as RoLo::Architecture::Data.
• InStream class (Table 136 and Figure 22): change type name of
  ‘setData’ method’s argument ‘value’ as RoLo::Architecture::Data.
• RoLo Service class (Table 140 and Figure 22): change type name of
  ‘adjust’ argument ‘data’ as RoLo::Architecture::Data.
  Modify C++ PSM as following:
• Add header files, Architecture.hpp and Interface.hpp, that represent
  Architecture package and Interface package respectively as following:
  // $Id: Architecture.hpp,v 1.3 2009/06/20 06:18:42 nishio Exp $
  #pragma once
  #include <RLS/RelativeCRS.hpp>
  #include <RLS/MobileCRS.hpp>
  #include <RLS/MobileOperation.hpp>
  #include <RLS/Identity.hpp>
  #include <RLS/ErrorType.hpp>
  #include <RLS/Error.hpp>
  #include <RLS/RoLoArchitecture.hpp>
  #include <RLS/RoLoDataOperation.hpp>
  // $Id: Interface.hpp,v 1.2 2009/06/20 06:18:43 nishio Exp $
  #pragma once
  #include <RLS/Ability.hpp>
  #include <RLS/Service.hpp>
• Reorder header files in C++ PSM so that files are ordered based on the
  packages they belong to. The files will be in the following order:
  Returncode_t.hpp, Architecture.hpp, RelativeCRS.hpp, MobileCRS.hpp,
  MobileOperation.hpp, Identity.hpp, ErrorType.hpp, Error.hpp,
  RoLoArchitecture.hpp, RoLoDataOperation.hpp, DataFormat.hpp,
  Interface.hpp, Ability.hpp, Service.hpp
• Move definitions in Error.hpp, ErrorBase.hpp, ErrorType.hpp,
  Identity.hpp, MobileCRS.hpp, MobileOperation.hpp, RelativeCRS.hpp,
  RoLoArchitecture.hpp and RoLoDataOperation.hpp into a namespace
  “::RoLo::Architecture”.
  Note: ErrorBase.hpp is added in issue 13185
• Move definitions in DataFormat.hpp into a namespace
  “::RoLo::DataFormat”.
• Move definitions in Ability.hpp and Service.hpp into a namespace
  “::RoLo::Interface”.
• Modify type of rla in SpecificDataFormat class (DataFormat.hpp)
  as ::RoLo::Architecture::DataSpecification.
• Modify type of ‘inStream’ and argument ‘inStream’ of getInStream()
  method in MobileDatum class (MobileCRS.hpp)
  as ::RoLo::Interface::InStream. Modify type of ‘dfList’ as ::RoLo::DataFormat::DataFormat and type of
  ‘rlaList’ as ::RoLo::Architecture::DataSpecification (Service.hpp).
• Modify type of ‘value’ argument of setData() method in InStream
  class (Service.hpp) as ::RoLo::Architecture::Data.
• Modify type of ‘value’ argument of getResult() method in OutStream
  class (Service.hpp) as ::RoLo::Architecture::Data.
• Modify type of ‘data’ argument of adjust() method in RoLo Service class
  (Service.hpp) as ::RoLo::Architecture::Data
  Disposition: Resolved

The constraint

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.

Fix Figure 7 according to the suggestions. However, as Particle class and
‘particles’ attribute in Particle Set class is removed in issue 13185, items in
summary related to these will not be revised. Also, for the relations Weighted
Distribution – Linear Mixture Model and Covariance Matrix – Gaussian are better
to be shown as compositions

-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

Fix Figure 5 according to the suggestions. However, the associations RoLo
Symbolic Position – DirectSymbol and RoLo Symbolic Position – RoLo Symbol
Ref shall be compositions both on RoLo Symbolic Position side. For the
associations SymbolicCRS – DirectSymbol and DirectSymbol – RoLo Symbolic
Ref, it is better to make them aggregations that indicate relevant attributes.

-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

Apply the necessary modifications to Figure 9 as specified. However, the
following relations are compositions and do not show derived attributes:
RoLo Position – ::ISO19107::GM_Position
RoLo Position – RoLo Symbolic Position
Position Element – RoLo Position
Position Element – RoLo Error
Error Element – RoLo Error
RoLo Data – RoLo Element
RoLo Element – RoLo Element Specification
Thus, for these relations, replace the associations to indicate composition with
corresponding attribute names.

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

Actually, this association is required between Specific Data Format and RoLo
Architecture, and not between User Defined Data Format and RoLo Architecture.
This association is for the ‘rla’ attribute of Specific Data Format class. Thus,
instead of adding note for limiting this association, we shall better correct the
association to be between Specific Data Format and RoLo Architecture that
shows the derived attribute ‘rla’ of Specific Data Format class. The new
association is also reported in issue 13998.

-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.

Correct the errata of UML diagram in Figure 10 (RoLo Data Operation) according
to the suggestions in the summary except for the first two issues, as they are
already in the diagram

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.

Fix Figure 4 according to the suggestions in the summary

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

Fix the description line by deleting the sentence in Table 5 beginning by "Holds a
RoLo Data that".

-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.

See issue 12920 for disposition

-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.

Fix Figure 3 according to the suggestions. However, for the first item, it is better
to make this an aggregation. For the second and third items on the associations
RelativeDatum - RoLo Data and MobileDatum – InStream,it is better to make
these relations as compositions.

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

Fix Figure 3 and relevant tables to show that these attributes derived from parent
classes are restricted in these child classes.

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

Fix Figure 3 according to the suggestions. However, for the second and the third
items, follow the resolution in issue 12920.

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?

See issue 13120 for disposition

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

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

All the class methods (functions) in beta1 specification’s C++ PSM were
returning Returncode_t value. Thus, the attributes marked as ‘out’ were handled
as by-reference arguments that were normally implemented by pointer passing.
Besides the C++ style pointed out in the summary, passing pointers are not a
good manner for effective development. Thus, we will change C++ PSM
definitions so that methods will use exceptions for passing return codes. The ‘out’
attributes will be passed as return values whenever possible.

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.

Flow controls for ‘getData’ and ‘setData’ methods in RoLo streams originally
assumed that flow control will be done by the underlying middleware. However,
as pointed out in the summary, it will lead to middleware dependency which is
not what we want. Thus, here we prepare some methods for controlling the flow.
We add three methods, ‘activate’, ‘deactivate’ and ‘isActivated’ to OutStream
class.

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

The RoLo abilities that RoLo streams and service instances hold shall be in an
aggregation relation, not in a composition relation. This is because several
instances of RoLo streams or services may share the same RoLo abilities. In
order to clarify this, we modify the UML diagram to show this explicitly.

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

Clarify the behavior of ‘setParameter’ method by adding description

(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

See issue 13439 for disposition

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

Correct the error.

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.

See issue 13322 for disposition

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.

See issue 13322 for disposition

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.

As specified in the summary, PUSH/POP in StreamType enumeration is not clear.
Here we alter the definition to make them clear.

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.

See issue 13322 for disposition

• 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.

Currently, pointers that indicate which RoLo position element specifications are
related to a RoLo error element specification are modeled to use ‘specID’
attribute in RoLo element specifications. Instead, as described in the summary, it
is much better to directly refer to the RoLo position element specification
instances. Thus, modify 'posSpecRef' to be an ordered list of references to
Position Element Specification instances and delete 'specID' attribute from RoLo
Element Specification class.
As RoLo Data Mapping Operation class depends on this, also modify
DataMappingOperation class definition to use the new data structure.
Additionally, some changes in C++ PSM are also required. Remove ‘specID’ from ElementSpecification class
(RoLoArchitecture.hpp)
– Change the definition of ‘posSpecRef’ class variable in
ErrorElementSpecification class (RoLoArchitecture.hpp) as following:
::std::vector<PositionElementSpecification*> posSpecRef;
– Change the name of ‘sourceIndex’ class variable in
DataMappingOperation (RoLoDataOperation.hpp) as
‘sourceElemSpecs’
– Change the name of ‘targetIndex’ class variable in
DataMappingOperation (RoLoDataOperation.hpp) as ‘targetElemSpecs’
– Change the definition of ‘sourceIndex’ and ‘targetIndex’ class variable in
DataMappingOperation (RoLoDataOperation.hpp) as following:
::std::vector<ElementSpecification*> sourceElemSpecs,
targetElemSpecs

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.

No Data Available

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.

Disposition: See issue 13120 for disposition

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.

Change the class name of RoLo Architecture to DataSpecification. However,
when the expression ‘RoLo Architecture’ is used in a sentence to describe an
object of this class, rewrite as ‘RoLo data specification’ instead of
‘DataSpecification’ to improve readability. Also change the names of attributes
that are typed to this class from ‘rla’ to ‘dataSpec’. However, for the ‘rla’ attribute
in RoLo Data class, change this to ‘spec’ so that the name will be consistent with
other elements of RoLo architecture.

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.

Extend common data formats each have two different interpretations so that they
can cover both of xyz-Euler's angle representation and roll-pitch-yaw
representation of orientation (two orientation representations for each Cartesian,
Polar, and Geodetic coordinate system). We thus have three common data
formats (syntax) each with two different RoLo data specifications (semantics).
We also add some figures in the specification to avoid misunderstanding or
ambiguity regarding the definition of position and orientation for each common
data format.
Also, based on issue 13999, change the types for timestamps in the common
data formats from a real number to two integers, which correspond to standard
UNIX C structure, time_t. Normally, the first integer indicates the number of
seconds elapsed from the epoch, and the second one indicates sub-seconds.
The unit of sub-seconds is normally nano second that is compatible to most
recent POSIX C time_t struct.

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

Disposition: See issue 13120 for disposition

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

Include PSM in the specification as section 8.1.

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).

No Data Available

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) ...

This issue is actually about 7.3.4, not 6.3.4.
Correct the erratum in Section 7.3.4 of RLS Specification Beta1 (robotics/08-07-
01). Note that the section number #6.3.4 in this issue is based on the previous
version of RLS Specification (robotics/08-05-02).

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

Correct typo as described in the summary.

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

Correct the errata

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].

Disposition: See issue 13119 for disposition

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)

See issue 13120 for disposition

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?