- From: Robin Berjon <robin@robineko.com>
- Date: Mon, 5 Oct 2009 12:38:08 +0200
- To: "Breitschwerdt, Christian, VF-Group" <christian.breitschwerdt@vodafone.com>
- Cc: "JOSE MANUEL CANTERA FONSECA" <jmcf@tid.es>, "Tran, Dzung D" <dzung.d.tran@intel.com>, <public-device-apis@w3.org>
Hi Christian! On Oct 5, 2009, at 12:04 , Breitschwerdt, Christian, VF-Group wrote: > I think Jose's requirement was alluding to the separation of API to > access system information on one side from the actual ontology (as in > http://www.w3.org/TR/dcontology/) on the other side. > > By example of the BONDI APIs for DeviceSatus > http://bondi.omtp.org/1.01/apis/devicestatus.html the API definition > itself does not say what system information it allows access to - this > is all handled by the BONDI name-spaced vocabulary. > > IMO the requirement is quite sensible but it bags the question how to > define baselines of vocabularies to be supported. Yes, I understand this, but I tend to think more in terms of API usability and am therefore reluctant to expose the fact that we're dealing with an ontology to developers. If you take an example from BONDI, you can write this: var level = device.getPropertyValue({property:"batteryLevel", aspect:"Battery", component:"_default"}); Which in fact can be simplified as: var level = device.getPropertyValue({property:"batteryLevel"}); But this begs the question as to why not simplify it further down to: var level = device.batteryLevel; As you say, if there is no required vocabulary, there is no interoperability, and therefore we're not solving developers' problems. If we do define a required vocabulary, then is there any reason not to expose it directly, in the way that is most convenient to the user? That leaves the question of extensions. I can think of two ways: // vendor based var foo = device.oDahut; var foo = device.mozDahut; var foo = device.msDahut; // pre-defined var foo = device.property("dahut"); My experience with the latter is that in the real world they never really get used, and they provide a false sense of "standard" or "well- specified" when in fact what one specifies in such cases is "accept anything, return anything" which in turn makes them untestable. The former is consistent with the way experimental DOM properties and CSS properties are introduced by vendors — when they later get accepted the prefix is simply dropped. It's not elegant (no solution is for this problem-space, I'm afraid) but it's functional and familiar. -- Robin Berjon robineko — setting new standards http://robineko.com/
Received on Monday, 5 October 2009 10:38:43 UTC