Hi, I believe that the most general API is always the best solution, it's easy to maintain and evolve. I did my question because when we're handling medical sensor data, we've a lot of complex types (for example, the blood pressure has at least two integer values, systolic and diastolic) and i didn't see any complext types in the Data format table of the Sensors API Specification. BTW, i don't know if i'm doing the question in the right place. I've just subscribed the mail list and after read some e-mails i guess that the sensors spec will handle only mobile device sensors and not external sensors. I'm right? Anyway, would be great if the sensors spec is able to attach new external sensors. BR, 2012/5/10 Marcos Caceres <w3c@marcosc.com> > Hi Marcos, > > On Tuesday, 8 May 2012 at 19:09, Marcos Fábio Pereira wrote: > > > What about medical sensors? Is there any discussion about this? > > I think it would be best to flip your question around: what use cases are > currently *not* covered by the proposed API? The term "medical sensor" is > kinda broad, as it could range from a temperature sensor, heart rate > monitor, to something that measures blood sugar levels, etc. It might be > that what you need is already covered implicitly given how general the API > is. > > Kind regards, > Marcos > > -- > Marcos Caceres > http://datadriven.com.au > > > > -- ------------------------------------------------------------- Marcos Fábio PereiraReceived on Thursday, 10 May 2012 10:21:27 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:37 UTC