Btw. some earlier arguments against W3C DDR was often that it finished in 2008. That was at least a year after the OMA UAProf "Best Practice Guides" (not a standard, more observations and guidelines) was released. And never got updated since.
WURFL at least in the past used UAProf as its raw data input. And the same data source also resulted in at least some of the DDR files we now got at DeviceMap. You'll see the origin everywhere it says "open_db_modified". While the WURFL XML file only shows a few traces of "OMA" strings or attribute names, the vast majority of even the Open Source ancestor never contained a reference of origin. Making it easier for them to claim "We invented it", but at least until 2011 it came right from those UAProf sources, too. Werner On Wed, Apr 1, 2015 at 10:52 PM, Werner Keil <[email protected]> wrote: > > > > Eberhard, > > inline > > On Wed, Apr 1, 2015 at 10:30 PM, eberhard speer jr. <[email protected]> > wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> If I understand correctly, I tend towards Reza's view. >> I too have been having some misgivings about the direction things are >> moving in : clients before data. >> Yes, the data is key and that highlights one issue : getting, storing >> and maintaining reliable data. >> Apart from that, somewhere along the line OpenDDR messed up the Aspect >> thing. >> > > OpenDDR just picked up the pieces as the WURFL/OMA community left it. You > see it in single files like WURFL.xml. > > https://svn.apache.org/repos/asf/devicemap/trunk/data/device-data/src/main/resources/devicedata/OperatingSystemDataSource.xml > is practically unused, but nobody prevented us and clients from using it. > I don't think > https://svn.apache.org/repos/asf/devicemap/trunk/data/device-data/src/main/resources/devicedata/BrowserDataSource.xml > > is used by any clients either, and except for the DDR client the builder > file is also more abused than used as intended. > Every entry in > https://svn.apache.org/repos/asf/devicemap/trunk/data/device-data/src/main/resources/devicedata/DeviceDataSource.xml > from "open_db_modified" indicates, these entries were shaped and defined > by some OMA data sources, that's where they got messed up;-) > > Unlike Werner I do not think that's just a question of untangling the >> current data. Like Reza -- if I understand correctly -- I think a >> "framework" not unlike OMA's UAProfiles, following the W3C standards >> is required -- by the way it seems to me that the W3C 'client' is just >> an [unfortunate] example of a client implementing the Vocabulary >> [Aspect/Attribute] and that the Vocabulary concepts developed are the >> meat of the standard, not the client. >> > > Untangling is one measure, it doesn't have to stop there. It depends on > who is willing to help with it and how regularly those people really get a > chance to do so. > > Note, a large portion of the WURFL/data related mess was driven by OMA in > the first place;-) If it did some work that is worth taking into > consideration, why not. The majority of its technologies (no real standards > though) or showcases circle around Device Management, especially for large > enterprise networks. Tracking and identifying a device is largely tied to > an individual handset and user, not just a devvice model > > >> >> On the .Net client : why try and force Java code and other conventions >> and practices on it ? >> Why burden it with stuff like log4net when anyone can wrap the minimal >> .Net client in anything they like and add logging IF they need it. >> I can imagine for debugging [use application log for that : faster, >> 'native', no dependencies] a log may be handy but otherwise it's >> ballast and dependencies. In the time it takes to log an even the >> client can parse, what 10, 100 user-agent strings... >> >> > If you refer to suggestions on JIRA, it's probably best to comment there > directly, avoiding a giant thread dealing with several things at once. > > Unlike the Java clients there is no real example on the .NET side other > than the console. Whether integrating the client in say an ASP.net > solution, I guess you know if you want do provide something like that or > not. > > >> So, I too await Reza's return -- had to look up "holiday" tho ;) >> >> >> > Enjoy yours, too, > Werner > > >> esjr >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2.0.22 (MingW32) >> >> iQEcBAEBAgAGBQJVHFV0AAoJEOxywXcFLKYc88oH/A36up91ipM/Rc54nYIpEh0u >> Wd0+LjC7pdronUKYU2bOmN6xPSOCg2SpJDnYRjKjebk59w6NxLYPOiKR0aBAV6TG >> HWyikxTt8QHlFHDiI9TUBifZWTzXhUmAdnrZWYDi+gtG0zZsoBlwAbjCCSMAkEUR >> hZtIUw/1UTyQH+TmnP0T6cnt/i0ZttjdsRR8JJSeQiW+kylxZuLQ6/2JX3F8xM+b >> zOJouK4oZJIUuoE1aCodcifHjeRvllg8V8ly63jPqAWWXojRLlBwoFqp2PLUSS4+ >> NMSVbIG04F/lcaTI+jFGgXT9vYfGIwK5u+OzdyOHAsr8q5w5wDtyTD+qATMgCLg= >> =ieOW >> -----END PGP SIGNATURE----- >> >> >
