add StringArray.msg

[k-okada]

as described in ros/std_msgs#5 , I'd like to introduce new data type, StringArray.msg somewhere in common_msgs. Do you have any suggestion on which package to put this msg?

$ cat StringArray.msg
string[] strings

we're using this type of message, for example obtain speech recognition result candidates.

https://svn.code.sf.net/p/jsk-ros-pkg/code/trunk/jsk_smart_apps/jsk_gui_msgs/msg/VoiceMessage.msg

[furushchev]

Is there any proceeding?
Is it no problem to put into an existing package or make a new package in common_msgs?

[tfoote]

Looking at this message I do not see it adding significant value by declaring such a generic datatype without semantic meaning. And without specific meaning there's no point in creating a single line msg file.

A well defined message should stand alone and be interpretable without any other context. For example a LaserScan captures the metadata as well as payload and any program knows what to expect when receiving the message.

A such you could propose setting up voice specific messages which would have meaning for voice recognition. However they should have strong semantic meaning so that the data can be interpreted effectively.

i'm not sure of your exact use cases but I would suggest something like:

VoiceRecognitionCandidates.msg
# This message represents the candidate phrases detected by voice recognition
String [] canidiates

or a more complex datatype

Where it's always known that VoiceRecognitionCandidates are differentiated from

Letter.msg
String [] sentances

Which is simply a collection of sentences. These could both be StringArray but have very different values.

Also when embedding a StringArray would require you to address the subfield using

my_msgs.strings.strings[0]

vs if you use the String [] type it could simply be

my_msg.strings[0]

[maxbader]

Hi

I just proposed a generic_msgs pkg (#49) maybe this would also solve your problem.

Greetings

[tfoote]

Closing as proposed messages don't have semantic meaning. See parallel discussion in #49.