Im open to switching the attributes back to camelCase. Thats the more accepted case for JSON anyway. Remember, nothing is set in stone right now.
A few other points... I am not too concerned what other projects or products do. DeviceAtlas, CC/PP, etc. My biggest concern is getting things right for this project. This means using sound and well practiced logic. Converting XML to JSON is going to be a handful of lines of scripting code. Not sure why you are thinking that would be a manual effort. On Fri, Jul 17, 2015 at 7:45 AM, Werner Keil <werner.k...@gmail.com> wrote: > Stefan/all, > > One good question to ask about a new JSON format are, whether or not to > abandon the accepted vocabulary or not. > http://wiki.apache.org/devicemap/AttributeSpec2 suggests some breaches, > e.g. changing "displayWith" or "displayHeight" to "display_width" and > "display_height" with no real reason other than putting a "_" there. > Same with "vendor" vs. "manufacturer". > > CC/PP which I investigate for offering Portlet 3 Device Profile support > backed by repositories like DeviceMap does not seem to define a vocabulary > as extensive as W3C DDR. > However, http://www.w3.org/TR/CCPP-struct-vocab/#ProfileAttributes shows > clearly, where the most common attributes like "displayHeight" are used, > their names are exactly identical to W3C DDR hence matching current > DeviceMap data. Not surprising, as most attributes and vocabularies are > based on groups like OMA and its members who gathered them in the past (and > some still do) > > If you're wondering about DeviceAtlas and their "new" JSON file. The actual > attributes are optimized and names scrambled into weird numeric UUIDs, but > the mapping to actual atttibute names > > > ["bisBrowser","bisChecker","bisDownloader","bisFilter","bisRobot","bisSpam","bisFeedReader","bmobileDevice","iid","bmarkup.xhtmlMp11","bmarkup.xhtmlMp12","buriSchemeTel","bhttps","imemoryLimitMarkup","imemoryLimitEmbeddedMedia","imemoryLimitDownload","bmidiMonophonic","bmidiPolyphonic","bamr","bmp3","baac","bqcelp","bmpeg4","b3gpp","b3gpp2","bwmv","bh263Type0InVideo","bh263Type3InVideo","bmpeg4InVideo","bamrInVideo","bawbInVideo","baacInVideo","baacLtpInVideo","bqcelpInVideo","bdrmOmaForwardLock","bdrmOmaCombinedDelivery","bdrmOmaSeparateDelivery","bcsd","bhscsd","bgprs","bedge","bhsdpa","bmarkup.xhtmlMp10","bmarkup.xhtmlBasic10","bimage.Gif87","bimage.Gif89a","bimage.Jpg","bimage.Png","bumts","iusableDisplayWidth","iusableDisplayHeight","smidp","scldc","bjsr30","bjsr139","bjsr37","bjsr118","bosSymbian","bosLinux","bosWindows","bosRim","bosOsx","sosProprietary","sosVersion","sdeveloperPlatform","sdeveloperPlatformVersion","buriSchemeSms","buriSchemeSmsTo","iyearReleased","b3gp.h264.level10","b3gp.h264.level10b","b3gp.h264.level11","b3gp.h264.level12","b3gp.h264.level13"," > b3gp.aac.lc > ","b3gp.h263","b3gp.amr.nb","b3gp.amr.wb","bmp4.h264.level11","bmp4.h264.level13"," > bmp4.aac.lc > ","bstream.3gp.h264.level10","bstream.3gp.h264.level10b","bstream.3gp.h264.level11","bstream.3gp.h264.level12","bstream.3gp.h264.level13"," > bstream.3gp.aac.lc > ","bstream.3gp.h263","bstream.3gp.amr.nb","bstream.3gp.amr.wb","bstream.mp4.h264.level11","bstream.mp4.h264.level13"," > bstream.mp4.aac.lc > ","bmarkup.wml1","bvCardDownload","btouchScreen","boma","bhttpDirectDownload","bosAndroid","svendor","smodel","idisplayWidth","idisplayHeight","idisplayColorDepth","sinputDevices","smarkupSupport","sstylesheetSupport","simageFormatSupport","sinputModeSupport","bcookieSupport","sversion","sscriptSupport"] > > shows clearly, their entire vocabulary in their W3C DDR compatible XML > format is also used by the JSON files. A Hungarian prefix like "i" for int > or "s" for String is the only difference. > > CC/PP just like W3C DDR also makes clear distinction between > device/hardware, OS/Software or Browser/UA. This has been there ever since, > the files dedicated to OS or Browser were just not used as intended and the > only aspect out of 3 or more was "device". > > Nobody with a sane mind and busy workload (as almost everyone here has;-) > would go and manually enter every single device. Even if a "crowd" effort > or harvesting it from friendly sites was picked up again, they usually > gather these based on accepted formats and naming schemes. Either you have > to translate everything or you lose precious information due to a name > mismatch. > > Werner > > On Thu, Jul 9, 2015 at 2:24 PM, Werner Keil <werner.k...@gmail.com> wrote: > > > Hi Stefan, > > > > Thanks for your reply and a fresh view on both data and clients. > > Note, the "contrib" section while it may not be technically r/o in SVN > > there is no more active development. It is more or less an "archived" > > historical view to some of the original contributions. > > We further modularized clients in recent months, so > > clients/1.0/java > > clients/1.0/java_w3c_simple > > already tell they belong together. > > One should have a dependency on the other, even if they may not be > modules > > using a common Parent POM at the moment (they should but as long as you > use > > the right version of "Classifier" for the W3C "Wrapper" it would work) > > > > W3C defined a very bulky test suite (e.g. a class with a 20-30 argument > > constructor;-O) which I started composing under > > clients/w3c-ddr/simpleddr/src/test/java > > > > Test runner is currently a standalone app, but it seems possible to > > convert it into an actual JUnit tests, though the test harness does a lot > > of things at once, and previous results of these tests mainly consist of > > console or HTML-generated results of a standalone app. > > > > On GitHub someone earlier compared OpenDDR to other solutions like > > 52DegreesMobi: > > https://github.com/samaxes/ddr-compare > > > > It should be possible to run his test at least against the W3C DDR > > DeviceMap client, too. Would be interesting to see, if data updates > > improved our results ideally compared to a recent version of other > products. > > > > The 1.0 "Wrapper" I did not try to run against the test harness. It is a > > partial implementation of the W3C DDR Simple API, so some aspects the > test > > expects may not even be there. If all test data is in place for the > > "classic" W3C DDR client, we could always try both. If an implementation > > passes all or most of the relevant tests, it may call itself "W3C > > compliant" against the DDR recommendation. > > > > You're more than welcome to help with either client(s) or just contribute > > to data, whatever you feel most comfortable with. > > As soon as you got a good enough picture of what's there;-) > > > > Werner > > > > On Wed, Jul 8, 2015 at 10:27 PM, Stefan Seelmann < > m...@stefan-seelmann.de> > > wrote: > > > >> Hi Werner, > >> > >> many thanks for the detailed explanation. > >> > >> I saw BrowserDataSource.xml and OperatingSystemDataSource.xml, but as I > >> found no "detection" patterns and as the also not loaded by the (Java) > >> devicemap-client I thought they are not used. > >> > >> The project contains lot of pieces, I didn't yet figured out how they > >> fit together. Initially I just saw and tried the official released Java > >> device-map client. Now I digged a bit deeper and there are (at least) 4 > >> Java clients in SVN > >> > >> clients/1.0/java > >> clients/1.0/java_w3c_simple > >> clients/w3c-ddr > >> contrib/openddr/java > >> > >> The one in "clients/w3c-ddr/simpleddr" actually is able to > >> detect/classify OS and browser including versions. It has lot of > >> specialized Builders which use regex matching to detect UAs (but e.g. > >> not Firefox on Windows). Support of an existing W3C API seems noble, but > >> with its data structructures and namespaces it is a bit cumbersome to > use. > >> > >> On the other hand the one in "clients/1.0/java" just seems to use the > >> patterns defined in BuilderDataSource.xml, without regex matching. It is > >> totally simple to use. > >> > >> I think it makes sense to define patterns in data files, as different > >> client implementations can use the same data. Hardcoded parsers are more > >> difficult to port to other languages/platforms. Regex is quite powerful > >> but probably slower than simple character matching. > >> > >> Sorry for dumping my findings and thoughts. I'm still try to find my way > >> into the project. > >> > >> Kind Regards, > >> Stefan > >> > >> > >> > >> On 07/08/2015 10:50 AM, Werner Keil wrote: > >> > Hello Stefan, > >> > > >> > Thanks a lot for your input. You're asking some good and constructive > >> > questions. > >> > > >> > With regards to what devices have a browser, this recent post on the > >> > DeviceAtlas (clearly the most visible and likely notable commercial > >> vendor > >> > in this field) page > >> > https://deviceatlas.com/blog/which-devices-have-browsers > >> > It contains devices like XBox or even Samsung Gear, etc. > >> > > >> > With regards to dealing with devices and browsers separately, the DDR > >> > standard and formats has always intended to do so, just look at > >> > > >> > https://svn.apache.org/viewvc/devicemap/trunk/data/1.0/device-data/src/main/resources/devicedata/BrowserDataSource.xml?view=co&revision=1686469&content-type=text%2Fplain > >> > but this and other XML files are clearly undervalued and barely used > >> > especially by the "Classifier" family of clients. > >> > > >> > Other clients due to their W3C DDR compliant heritage do, but if the > >> data > >> > is not maintained there, neither will get you proper results;-| > >> > > >> > You're right, that some of the visions around 2.0 can be promising if > >> > there's enough support by the community. Neither of us can do this > >> alone, > >> > and while some projects like this may be smaller than others, a key > >> reason > >> > to donate the codebase of OpenDDR here was to increase the community > >> where > >> > possible. > >> > > >> > Aside from a service-based approach > >> > https://deviceatlas.com/resources/dynamic-data > >> > DeviceAtlas also makes it pretty clear, their primary format is JSON > >> now: > >> > https://deviceatlas.com/resources/getting-the-data > >> > while it is safe to assume, other commercial closed-source > alternatives > >> > like WURFL still dance around the WURFL.xml even if they may have > >> stored it > >> > into some XML DB now, too;-) > >> > > >> > An important effort is, to transform existing device information (our > >> crown > >> > jewel after all;-) from XML to JSON once the new format or formats are > >> > defined and agreed on. Whether or not there's also a 2-way conversion, > >> we > >> > shall see. > >> > You can be sure, commercial closed-source vendors like DeviceAtlas > offer > >> > this but it's up to the community if we can and want to offer that as > >> well. > >> > > >> > Contributing e.g. via JIRA or (I think you may also self-register for > >> that) > >> > the Wiki would be a good start. If you have concrete patches or code > >> > contributions, attaching them (as patch, diff or "snippet") to a JIRA > >> > ticket is a good practice to start helping. For some this lead to > >> becoming > >> > a full committer, so we'd welcome others to do so if they help on a > >> regular > >> > basis. > >> > > >> > Thanks and Regards, > >> > > >> > Werner > >> > > >> > On Wed, Jul 8, 2015 at 12:24 AM, Stefan Seelmann < > >> m...@stefan-seelmann.de> > >> > wrote: > >> > > >> >> Hello, > >> >> > >> >> I have the need to classify not only mobile devices, but also desktop > >> >> browsers and other clients (e.g. email clients) including operating > >> >> system and versions. The current state of DeviceMap seems not > suitable > >> >> for this, for example Firefox and Chrome are just classifed as > >> >> "desktopDevice". > >> >> > >> >> I already tried to add patterns to BuilderDataSourcePatch.xml and > >> >> DeviceDataSourcePatch.xml. That somehow worked, but if I understand > the > >> >> data format correctlry I'd have to create one "device" per > >> >> OS+version/browser+version, which would result in an insane number of > >> >> combinations. > >> >> > >> >> Is there a better way to define data using the version 1 device data > >> >> format to achive my needs? > >> >> > >> >> > >> >> I also browsed the wiki and mailing list archive. The "Device Data > 2.0" > >> >> specification looks very promising to me. There seem to be neither > code > >> >> nor data (not even prototypes) available. Based on mailing list > archive > >> >> I'm even not sure if there is consensus among the developers go for > >> this > >> >> new data format. > >> >> > >> >> Are there plans within the community to develop the version 2? > >> >> > >> >> How can I help (with limited resources...)? > >> >> > >> >> > >> >> Kind Regards, > >> >> Stefan > >> >> > >> > > >> > >> > > >
