I meant the current state of data will have to be converted once the target format in JSON is set. And where users of the XML format benefit (the match of attributes indicates, big vendors like DeviceAtlas do this on a regular basis) it may well be bi-directional.
While others added later we could decide to drop or introduce even newer ones, the Core Vocabulary http://www.w3.org/TR/ddr-core-vocabulary/ is probably a good thing to keep under those names. On Fri, Jul 17, 2015 at 3:01 PM, Reza Naghibi <re...@apache.org> wrote: > 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 > > >> >> > > >> > > > >> > > >> > > > > > >
