Sure, if you are going to *rename* a field, just shoot an email out so people are aware cause it may affect downstream users (ex: dclass).
________________________________ From: Werner Keil <[email protected]> To: "[email protected]" <[email protected]>; Reza <[email protected]> Sent: Thursday, July 31, 2014 3:42 PM Subject: Re: generic desktops, crawler, and generic android I am fine, see "isApple" or "isPalm" they are equally weird. If you feel OK sticking to the OMA *CC/PP UAProfile extended vocab list * we may rename those that ODDR added in parallel while keeping those specific fo ODDR as they are. Werner On Thu, Jul 31, 2014 at 9:35 PM, Reza <[email protected]> wrote: > So I talked to Eberhard (its easier in skype), regarding the bad defaults > he is referring to fields in generic- like nokia_edition. I agree. We > should go ahead and prune out some of these weird fields. > > Also, I just noticed that genericCrawler parents generic-, so it has a > bunch of incorrectly inherited fields. > > > ________________________________ > From: Reza <[email protected]> > To: "[email protected]" < > [email protected]> > Sent: Thursday, July 31, 2014 3:19 PM > Subject: Re: generic desktops, crawler, and generic android > > > Sounds good to me, can you go ahead and commit these changes? > > > ________________________________ > > From: Werner Keil <[email protected]> > To: "[email protected]" < > [email protected]> > Sent: Thursday, July 31, 2014 3:16 PM > Subject: Re: generic desktops, crawler, and generic android > > > About bot vs. crawler, I'd be happy with either of them. > > Please let's not polute the > <!-- ODDR property --> > section in the vocabulary, but add a new > > <!-- DeviceMap property --> > block in that file. > > "vendor" for a Windows desktop is just wrong, as I assumed. > For Apple it is different, but if "Microsoft" should be maintained, then we > needed > "device_os_vendor" just like "device_os_version" already defined by ODDR. > > Last but not least, for newly added device descriptions, even if they were > copied or refactored from the patch file, could we also try to use the > "from" field ODDR declared? > This is sort of the origin of the data, so for anything added new it would > be "devicemap", while earlier entries originate from "oddr" or > "open_db_modified" > > Werner > > > > > On Thu, Jul 31, 2014 at 9:04 PM, eberhard speer jr. <[email protected]> > wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Hi, > > > > a lot of 'topics' in this thread, so... > > > > - - 1600x900, 800x600...defaults > > > > I repeat : "...unless the API client specifically requests it [cfr W3C > > API] *not* to include any 'default' values." > > > > why : the API client cannot tell a 'default' from an actual value. > > [A missing value on the other hand would allow the client the option > > to implement a default they know and which makes sense in their > > current context.] > > > > > > - - is_crawler > > > > I would suggest : isBot > > > > why : "bot" is a 'known' on the internet, 'crawler' is not as well > > understood and "bot" is shorted. > > > > Rather than introducing more underscores for 'backward compatibility', > > since we are reviewing the properties, removing those things makes > > more sense. It's shorter and 'nicer' : assuming the 'device' is a > > key/value pair collection, in 'pseudo' code this comes out as : > > > > thisProperty = kvCollection[Property] > > if thisPropety is null apply meaningful default > > else...as you were... > > > > or, for example : > > > > bool isBot = Device[isBot]; > > > > > > > > esjr > > > > > > > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v2.0.22 (MingW32) > > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > > > iQEcBAEBAgAGBQJT2pMuAAoJEOxywXcFLKYc5ZoH/3OVR0qsOduyrncr0Gd4aUA6 > > FQ0hc5Z2yXWx7bVWqF77RZFkOGJZuOURsvrffrYO8NV7zB6qUAdm5I/O5SWDPBni > > lkR7CdUbrg2lqp2tM9vCVd1N3rL2w3YU7wfkUxhYg8A8UMRQbbDFoqKzJs4TpuJ6 > > gQt2gUu8FDt46bg561/80iD/OgRf7KGR+TUp3gHOZXxoSx0Uu7XhMm+W+yGZ5b6Q > > 458RAOtEFG5YkbqppXuQbxHiGkT6HRa2CuI1MjZ8ljo0UCrEw54ZDdHcfWz9YXiA > > /HD4b7VMGB0opyc75P+lIMEOtVwLdll2QOhKgnWWWawBZpPVfQf8YuutQqQpPBw= > > =E5i3 > > -----END PGP SIGNATURE----- > > >
