devicemap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Werner Keil <werner.k...@gmail.com>
Subject Re: 2.0 parameter format
Date Mon, 02 Feb 2015 17:57:06 GMT
For all kinds of values yes, see an example
http://www.phonearena.com/phones/Samsung-Galaxy-V_id8971
"screen-to-body-ratio" or "front-facing camera" etc. but not sure, if we
needed to maintain so many, especially the more exotic ones in our data
anyway.
If we did, storing it internally as "screen_to_body_ratio" or similar
should be fine. The representation above is also just a UI improved version
that's human readable, doesn't mean they store this in a DB or other format
like that.

Werner



On Mon, Feb 2, 2015 at 6:26 PM, Reza Naghibi <reza@naghibi.com> wrote:

> There are no dashed values in the actual data. However, its a popular
> format for device specs.
>
> On Mon, Feb 2, 2015 at 6:43 AM, Werner Keil <werner.keil@gmail.com> wrote:
>
> > Sounds fair, if we prefer "param_name" then the ODDR/OMA style like
> > "is_tablet" seems beneficial;-)
> >
> > Where did you find a dash (-) in names or properties?
> > And what about values? Especially top level entries like "generic-" also
> > contain dashes
> >
> > Werner
> >
> > On Mon, Feb 2, 2015 at 10:02 AM, Volkan Yazıcı <volkan.yazici@gmail.com>
> > wrote:
> >
> > > +1
> > >
> > > On Fri, Jan 30, 2015 at 4:42 PM, Reza Naghibi <reza@naghibi.com>
> wrote:
> > >
> > > > So Ive been working thru the 1.0.2 data and its clear that the data
> > > > parameter format is officially all over the map. Camel case,
> > underscores,
> > > > and dashes are used throughout. So im going to go ahead and propose
> > > > snake_case for 2.0. Here are some of my thoughts:
> > > >
> > > > -JS/JSON parameters are problematic when dashses are used, so thats
> > kind
> > > of
> > > > a reason to eliminate the dash.
> > > > -Camel case uses a mix of cases which can be error prone. This may be
> > > more
> > > > of an observation than an actual argument.
> > > >
> > > > Im pretty open here, so if there are good reasons to go in any
> > direction,
> > > > lets hear them.
> > > >
> > > > As for converting our current data, its pretty simple to convert
> > > camelCase
> > > > to camel_case and dashed-params become dashed_params.
> > > >
> > > > So once I get the 1.0.2 release done, I will start work on the actual
> > > JSON
> > > > format specification for 2.0. Once that is done, I think 2.0 will be
> > > ready
> > > > for dev.
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message