[clarify] ApplicationVersion property of DeveloperDataId mesg is unspecified

[CrewNerd]

Section

1.4, Application ID

The text in question

All developer fields defined in this standard MUST use the standard's application ID to prevent namespace collisions.

Format: 16-byte UUID array as required by FIT SDK DeveloperDataIdMessage

UUID: 89e86158-6d47-5c98-9d46-7d29437f27b9

This UUID v5 is deterministically generated from DNS namespace with name "rowingdata" (uuid.uuid5(uuid.NAMESPACE_DNS, 'rowingdata')), ensuring consistency across implementations. The FIT SDK requires the application_id field to be a 16-byte array representation of this UUID.

The readings you can see

Data producers will have to emit a DeveloperDataId mesg. The FIT standard (https://developer.garmin.com/fit/cookbook/developer-data/) describes the optional "application version" property. I propose that we use this property to convey the version of the rowing data standard (protocol) that the data is intended to conform to.

I suggest that we decouple the version of the specification and the protocol, since most specification updates will not require a change to the protocol. Further, I suggest that the protocol version be changed only in the event of breaking changes to the protocol (which should be exceedingly rare). For example, adding a new custom field is not a breaking change.

What did you do?

No response

Your context

CrewNerd

[CrewNerd]

In the old repo, there was a suggestion to add the RecordingStrategy to the DeveloperDataId mesg, but I don't think this will work since the FieldDescription messages come AFTER the DeveloperDataId mesg.

[JaapvanEkris]

I just tested it. The SDK indeed complains about using a developer field before using it. Moving the dev fields forward might technically work, but might hit unexpected incompatibility issues as putting dev fields so early might be confusing for consumers.

Another potential place might be 'device info', where the recording strategy might actually have a good natural fit. Similar would be the claimed level of comliance.

[CrewNerd]

In my testing, the Swift SDK didn't complain, but FITFileViewer showed that the property wasn't actually written. I just tried putting it on the 'device info' and ran into the same problem there.

[JaapvanEkris]

Here the same with the Garmin FIT SDK. It seems to be dropped silently (tried GoToes Fitviewer as well). I think the Session level is the next best thing then...