Re: Advice on how to best handle a long list of attributes

Thanks Tab!

In addition to units, the Bluetooth SIG also defines Service UUIDs
(https://developer.bluetooth.org/gatt/services/Pages/ServicesHome.aspx),
Characteristic UUIDs
(https://developer.bluetooth.org/gatt/characteristics/Pages/CharacteristicsHome.aspx),
and Descriptor UUIDs
(https://developer.bluetooth.org/gatt/descriptors/Pages/DescriptorsHomePage.aspx).
The Services, Characteristics, and Descriptors are likely to be used
much more widely by users of the Web Bluetooth API than the Units.

The Bluetooth SIG extends these lists periodically, so the fact that
they named the "heart_rate" service and the "heart_rate_measurement"
characteristic differently doesn't mean they'll never define a
collision across these lists. I haven't found a formal commitment not
to, although I haven't asked their mailing list. This seems to push
for defining all of BluetoothUnitMap, BluetoothServiceMap,
BluetoothCharacteristicMap, and BluetoothDescriptorMap. Is that right?

If possible, I'd like to find a way to say "define the same names the
Bluetooth SIG currently defines" without having to copy them all into
our spec. However, that conflicts with trying to fix up name
collisions. If we do copy the names into our spec and fix up
collisions, I'm worried that we'll confuse developers by telling them
to look in one place for the names and another for the definitions.
(And the definitions absolutely belong with Bluetooth, not with our
spec.)

Whatever we do with naming, there's also the stylistic questions of
how to expose them:
1) Does the web prefer navigator.foo.bar or window.FooBar?
2) Does the web prefer an object with attributes or a Map?

You seem to be leaning toward window.FooBar and a Map. Can you explain
why and in what circumstances those choices are better than the
alternatives, so I can make the right guess next time?

Thanks again,
Jeffrey

On Thu, Sep 25, 2014 at 4:55 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Thu, Sep 25, 2014 at 4:09 PM, Marcos Caceres <marcos@marcosc.com> wrote:
>> The Web BlueTooth API currently specifies interfaces that serve as lookup tables for values [1], which can lead to code that looks like this (extreme example):
>>
>> ```
>> //returns a UUID string
>> navigator.bluetooth.uuids.catalytic_activity_concentration.katal_per_cubic_metre
>> ```
>>
>> Clearly, that's not ideal to type out. I'm wondering if anyone has some recommendations of how we can clean this up a bit. We've thrown around some ideas [2], like using a WebIDL [MapClass] to look up values using enums:
>>
>> ```
>> BluetoothUnitMap.get("katal_per_cubic_metre");
>> ```
>>
>> or exposing things like the above as static constants on interface objects:
>>
>> ```
>> BluetoothUnitMap.catalytic_activity_concentration.katal_per_cubic_metre
>> ```
>>
>> ... but nothing feels quite right :/
>>
>> Can anyone think of a better way of approaching this problem? Maybe it doesn't matter?
>>
>>
>> [1] https://webbluetoothcg.github.io/web-bluetooth/#standard-gatt-units
>> [2] https://github.com/WebBluetoothCG/web-bluetooth/issues/49
>
> Looking through the list, these are the only entries with duplicate leaf names:
>
> * surface_charge_density.coulomb_per_square_metre
>   electric_flux_density.coulomb_per_square_metre
>
> * density.kilogram_per_cubic_metre
>   mass_concentration.kilogram_per_cubic_metre
>
> * time.minute
>   plane_angle.minute
>
> * time.second
>   plane_angle.second
>
> * heat_flux_density.watt_per_square_metre
>   irradiance.watt_per_square_metre
>
> The minute/second ones can just be renamed to use arcminute and
> arcsecond or something.  The other three pairs appear to be identical
> units; the "density" and "irradiance" pairs even appear to be
> identical uses!  (The electric one might be too, but I don't feel like
> looking up those terms to see how comparable they are.)
>
> So yes, just producing a flat unit map seems just fine, with the
> time/angle collision sorted out.
>
> (It looks like these are all from an existing standard, so it wouldn't
> be worthwhile to try and produce a more robust system of units,
> right?)
>
> ~TJ

Received on Friday, 26 September 2014 00:30:29 UTC