Re: ISSUE-14: Gathering requirements [System Info & Events]

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