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 >> >> >> > >> >> >
