RE: ACTION-16 for SystemInfo API

Jose,
The ability to derive that the user is roaming (and also whether this is international) through the MCC & MNC should be enough, if we have both the 'homePLMNetwork' and 'connectedNetworks' (connected network is already proposed in the SysInfo API, though not as an array).

I agree about the Operator Name varying, especially if you consider internationalization. But the mapping between MCC/MNC and Operator may not be something easy for developers.

I agree that the DCO should provide the model and semantics of the data. The key thing to check is that any properties specifically exposed through an interface (as compared to a generic interface such as SystemInfo) are aligned with the semantics in the DCO.

Thanks, 
Bryan Sullivan | AT&T
-----Original Message-----
From: JOSE MANUEL CANTERA FONSECA [mailto:jmcf@tid.es] 
Sent: Thursday, February 25, 2010 5:07 AM
To: SULLIVAN, BRYAN L (ATTCINW); public-device-apis@w3.org; public-uwa@w3.org
Subject: RE: ACTION-16 for SystemInfo API

Hi Bryan,

Your comments on possible additions to the DCO coming from the input provided by the SysInfo API are sensible. However,  I'm in doubt about 'roaming' and 'operatorName' 

'roaming' is a derived property and can be inferred from the following properties

'homePLMNetwork' and 'connectedNetworks' in the sense that if the device is connected to any PLMNetwork different than the 'homePLMNetwork'then the device is in roaming

I agree that it can be more convenient to have a 'roaming' property but we have to be sure to provide precise semantics to such a property. Maybe, ITU, ETSI or similar has strictly defined when a device is in roaming ...

With regards to the 'operatorName' I'm questioning the utility of this property as this string can vary a lot. so If I were a developer I wouldn't rely on this property but on the 'mnc' and 'mcc' properties. 

As a last comment I'm open to add to the ontology any property the SysInfo necessitates, provided that the ontology remains as the normative document that provides the precise semantics of each property ... 

Best Regards

-----Mensaje original-----
De: public-uwa-request@w3.org [mailto:public-uwa-request@w3.org] En nombre de SULLIVAN, BRYAN L (ATTCINW)
Enviado el: martes, 23 de febrero de 2010 10:12
Para: public-device-apis@w3.org; public-uwa@w3.org
Asunto: ACTION-16 for SystemInfo API

Hi all,

Here are some further comments on the SystemInfo API. I have finished
reviewing the document and comparing it with the DCO and other standard
vocabularies. I am making a second pass to begin the process of
alignment, extension, and in general commenting on the current draft's
properties. I am preparing a detailed proposal as I mentioned, to be
ready by the Prague F2F. In the meantime I will be making specific
proposals on the items in the current draft, as I get time. 

This however is not a quick process, and DAP should not rush it. It will
take some time to create a normative set of properties that we want to
include in this first version. We will need to spend adequate time
discussing each one, to be sure we are aligned with the existing
standards work in W3C and elsewhere (e.g. OMA), and are including all
properties for which it is clear that a broad consensus considers them
important in this first SystemInfo API version. We can really only
determine that effectively by creating, as a group, what we consider a
complete set of high-priority first-release properties, and then putting
that out for public review and input on additional properties of
importance. We need to ensure that the UWA group is aware of the
discussions and has a chance to provide input as well.

Here are comments to the Power and Network properties.

Power.level should be aligned with the DCO (hard:batteryLevel (0 to 100
inclusive)).

Power.isExternal is redundant with Power.isCharging. batteryBeingCharged
(DCO hard:batteryBeingCharged) is a clearer name.

Power.timeRemaining is useful but should be described "Represents the
estimated time remaining in seconds before the battery will be depleted,
based upon current power usage. If batteryBeingCharged is true, this
value must represent the estimated time remaining in seconds before the
battery would be depleted, based upon current power usage, if external
power were removed." It should also be added to the DCO
(hard:batteryTimeRemaining).

Network: add TYPE_LTE

Overall, for network info the model provided by the DCO is more complete
and contains additional useful info on networks that are active,
available, supported, default, and preferred. 
    net:availableNetworkBearers
    dcn:currentNetworkBearer (note: in the DCO this should be
dcn:currentNetworkBearers as there may be multiple active networks)
    net:defaultNetworkBearer
    net:preferredNetworkBearer
    net:supportedNetworkBearers

operatorName is a useful convenience property and should be added to the
DCO (dcn:operatorName).

roaming should have three values: national, and international. If not
roaming, the value should be null. This should also be added to the DCO
(dcn:roaming).

Thanks, 
Bryan Sullivan | AT&T

Received on Monday, 1 March 2010 15:30:20 UTC