I am designing a custom GATT profile for a mobile robot base to connect to a tablet. Among other things, the base is reporting its position in x and y coordinates. The question is, how should I organize these two values in the GATT profile? Should they be contained in two individual characteristics or should I lump them together in one characteristic. E.g. (I left out UUID's for brevity):
<Service name="Odometry Service">
<Characteristic name="Base Position" >
<Value>
<Field name="Position on the X axis">
<Format>sint32</Format>
<Unit>org.bluetooth.unit.length.metre</Unit>
<Exponent>-3</Exponent>
</Field>
<Field name="Position on the Y axis">
<Format>sint32</Format>
<Unit>org.bluetooth.unit.length.metre</Unit>
<Exponent>-3</Exponent>
</Field>
</Value>
</Characteristic>
</Service>
or
<Service name="Odometry Service">
<Characteristic name="Position on the X axis" >
<Value>
<Format>sint32</Format>
<Unit>org.bluetooth.unit.length.metre</Unit>
<Exponent>-3</Exponent>
</Value>
</Characteristic>
<Characteristic name="Position on the Y axis" >
<Value>
<Format>sint32</Format>
<Unit>org.bluetooth.unit.length.metre</Unit>
<Exponent>-3</Exponent>
</Value>
</Characteristic>
</Service>
Obviously, technically, I can do both, and looking at the official Bluetooth adopted characteristics some characteristics lump the information together e.g. the Location and Speed characteristic used in the Location and Navigation service. Where the Indoor Positioning Service reports latitude and longitude in individual characteristics.
On one hand it makes sense to lump them together as the a change in position would likely change both values, and result in only one indication on the client side. On the other hand the client needs to do bit fiddling to get the values, which would be easily handled if they were individual characteristics.
I cannot seem to find a recommendation in the specification, and the adoption of both types seem to indicate that it is up to me? However, I may have missed a point somewhere.
TL/DR: Pack the values together
I've used sensors that report accelerometer in a single attribute and also ones that separated the axis into separate attributes. Neither is right or wrong, it all depends on your application.
However, when the values are separated you end up with some problems if you wish to use the axis values together. If you get a notification/indication that an axis has changed, you'll only get that value reported and have to assume the value of the other. If both axis have changed values, you'll get the two indications separately and it's a bit of a race condition.
Think about it like this:
You're currently X, Y value is (1,1) and then the value changes to (2,2). If you have the values packed together in a single attribute you'll get this:
If you have them separate you'll get this (as on possible situation):
The major question is, are you okay with having that intermediate state of (2,1) that probably isn't an actual state of the device? It's also just as likely to get a (1,2) state depending on which axis registered the change first.
Reading over your question again, I'm not really sure if either of your choices reflect what I'm saying in my case #1... What you want to do is have a single value reported that contains both X and Y values in a single binary and the listening end then has to unpack. I'm not familiar with the notation you're using so I'm not sure if that's what your first choice is doing or not.