devicemap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reza Naghibi <r...@naghibi.com>
Subject Re: 2.0 parameter format
Date Mon, 02 Feb 2015 17:26:17 GMT
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