- From: Marcos Fábio Pereira <marcos.pereira@signove.com>
- Date: Thu, 10 May 2012 07:14:52 -0300
- To: Marcos Caceres <w3c@marcosc.com>
- Cc: public-device-apis@w3.org
- Message-ID: <CAG_XX+4RqQ9GUKt5pnWV1MW7Ow42wQpUB1va5qknN_cCJQxVOA@mail.gmail.com>
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 Pereira
Received on Thursday, 10 May 2012 10:21:27 UTC