You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@devicemap.apache.org by Volkan Yazıcı <vo...@gmail.com> on 2015/02/02 10:02:21 UTC
Re: 2.0 parameter format
+1
On Fri, Jan 30, 2015 at 4:42 PM, Reza Naghibi <re...@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.
>
Re: 2.0 parameter format
Posted by Werner Keil <we...@gmail.com>.
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 <re...@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 <we...@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ı <vo...@gmail.com>
> > wrote:
> >
> > > +1
> > >
> > > On Fri, Jan 30, 2015 at 4:42 PM, Reza Naghibi <re...@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.
> > > >
> > >
> >
>
Re: 2.0 parameter format
Posted by Reza Naghibi <re...@naghibi.com>.
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 <we...@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ı <vo...@gmail.com>
> wrote:
>
> > +1
> >
> > On Fri, Jan 30, 2015 at 4:42 PM, Reza Naghibi <re...@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.
> > >
> >
>
Re: 2.0 parameter format
Posted by Werner Keil <we...@gmail.com>.
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ı <vo...@gmail.com>
wrote:
> +1
>
> On Fri, Jan 30, 2015 at 4:42 PM, Reza Naghibi <re...@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.
> >
>