[aprssig] Part 2: APRS device identifiers (tocalls) in YAML, XML and JSON

[Andrew Pavlin]

 Greetings, all.
I was delighted to see that Hessu is still keeping his YAML, XML, and JSON dumps of the APRS tocall database up to date (see thread starting at http://www.tapr.org/pipermail/aprssig/2013-October/042435.html for details of what I'm typing about). However, I'm wondering if it could be improved beyond the basic station "class" to add more information about hardware or software capabilities.
I'm thinking of optional attributes describing specific capabilities of the hardware/software, where the attribute is simply missing if Hessu doesn't know and the device/software creator won't tell him, and exists with suitable values if Hessu (and helping friends) do know. Hessu has already defined a "features" subtag and missing attributes here means the feature either doesn't exist on the specified hardware or software or it is unknown whether it exists(per my previous statement). I suppose this is OK, but clarifying this ambiguity by adding optional subvalues to the feature names to say "configurable" (user has to explicitly turn it on, not there by default) or "always" (can't be turned off) or "no" or "never" (for features normally expected but not available, such as receiving on a transmit-only tracker) might be useful. His classes are useful, but don't necessarily describe all of what a particular device or program can do. For example, KJ4ERJ's APRSIS32 program is listed as class "software", but it is capable of functioning as an I-gate if configured to do so.
So far, I see he has provided the feature subtags:   
   - messaging
   - item-in-msg
I am proposing to add the feature subtags:   
   - digipeater (for multi-function software)
   - I-gate
   - Tx (for receive-only software?)
   - Rx (for transmit-only trackers?)
   - QRU-client
   - QRU-server
   - telemetry-Tx (values could identify what type of telemetry data is sent [such as voltage and temperature by a Byonics TinyTrak 4])
   - Wx or weather (for a station with weather sensors, especially a multi-function station that does more than report weather)
   - sensor (value would identify what type of sensor, other than weather station sensors or a GPS)
   - query (answers broadcast queries)
   - directed_query (answers directed queries, value might be list of query commands answered)   

   - telecommand
   - timeslot (capable of transmitting in assigned and configured timeslots to reduce collisions, rather than just CSMA random access)   

   - gps (if one is included in the hardware or configurable in the software)
This additional information might help software authors better figure out what functions to enable for a particular remote station. For example, there's no point in giving a user the option to ask for the heard station list on a transmit-only tracker that won't hear anything, let alone the query to list what it heard.
Just my $.02.
Andrew Pavlin, KA2DDOauthor of YAAC ("Yet Another APRS Client")http://www.ka2ddo.org/ka2ddo/YAAC.html

P.S. To get things started, the feature subtags for YAAC (assuming we keep the above definitions) are:
messagingitem-in-msgdigipeater: configurableI-gate: configurableQRU-clientQRU-server: configurableWx: configurablequerydirected_querytimeslot: configurable
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20160319/c1ba7cd3/attachment.html>