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 <[email protected]> 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ı <[email protected]> > wrote: > > > +1 > > > > On Fri, Jan 30, 2015 at 4:42 PM, Reza Naghibi <[email protected]> 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. > > > > > >
