That's not exactly true, especially for essential information like "vendor"
W3C Core Vocabulary took 2 aspects into consideration, OpenDDR added
precision:
<Property name="vendor" datatype="xs:string" aspects="*device, webBrowser,
operativeSystem*" defaultAspect="device"/>
And at least the BuilderDataPatch contains some weird hacks that make no
real sense, like
<builder class="org.apache.devicemap.simpleddr.builder.device.
*AndroidDeviceBuilder*">
<device id="desktopDevice">
<list>
* <value>macintosh</value>*
* <value>windows nt</value>*
<value>x11</value>
</list>
</device>
A patch that initial OpenDDR data used merely for specific Android devices
like the Kindle Fire.
While
<builder class="org.openddr.simpleapi.oddr.builder.device.SimpleDeviceBuilder">
<device id="desktopDevice">
was where desktop devices, even if just the browser matches got extra
recognition support.
Looking at the simple OpenDDR Filter, it shows pretty much the same results
for Windows right now as the Client does:
desktop resolution: 800 x 600
Only few attributes are actually used, but the ones that are show, that
windows is recognized as "desktopDevice", too.
Werner
On Wed, Jul 30, 2014 at 2:53 AM, Reza <[email protected]>
wrote:
> So its important not to confuse devices with browsers and operating
> systems. They are all separate entities and a User-Agent contains *ALL
> THREE*.
>
> Right now our device-data only has patterns to detect devices. ODDR never
> expended to include these other entities. So right now DeviceMap does not
> directly detect browsers or operating systems. OS is indirectly detected
> via a device attribute because phone operating systems are pretty static.
>
> In dclass, there is actually a different pattern set used to detect
> browsers and operating systems:
>
>
> https://github.com/TheWeatherChannel/dClass/blob/master/dtrees/browser.dtree
>
>
> So right now DeviceMap only detects desktopBrowser as a *generic device*.
> Its not as detailed as http://www.useragentstring.com/index.php because
> they are doing browser and OS detection.
>
> Long term, we should build out the data to detect browser and OS.
>
>
> ________________________________
> From: Werner Keil <[email protected]>
> To: "[email protected]" <
> [email protected]>
> Sent: Tuesday, July 29, 2014 8:43 PM
> Subject: Re: Take stock
>
>
> Well there are 2 aspects, one API, the "new/alternate" client may evolve,
> and putting those things in JIRA is not wrong.
> Whether the person responsible for a component (i.E. Reza for the Java
> client or yourself for .NET) just picks something or there is some sort of
> "voting process" (with a series of +1 or similar, see Eclipse, I also
> recall having heard about that somewhere here) that is probably worth
> considering.
>
> Even though design patterns are applied in most modern languages, not
> everything might be applied exactly the same way on the .NET side, so if
> you don't see the need of a "factory" for something there, just leave it.
>
> The data can use some care, not just for brand new platforms, and IMHO
> adding a reliable recognition of new families like Firefox OS, Blackberry
> 10 or Windows Phone 7 or 8, the certain age of the baseline means there's a
> lot to do and no need to wait. We may rarely have JIRA tickets other than
> from actual committers now, but even on GitHub there are one or two ODDR
> either overlooked or did not consider a high priority including a fix for
> BlackBerry OS which we are probbly still missing in the current
> device-data.
>
> I'm afraid, the "desktopDevice" doesn't add that much value right now,
> given I see:
> model: browser
> ajax_support_getelementbyid: true
> marketing_name: -
> displayWidth: 1600
> id: desktopDevice
> device_os: -
> xhtml_format_as_attribute: false
> is_crawler: false
> dual_orientation: false
> nokia_series: 0
> device_os_version: -
> nokia_edition: 0
> vendor: desktop
> mobile_browser_version: -
> ajax_support_events: true
> is_desktop: true
> ajax_support_inner_html: true
> image_inlining: false
> mobile_browser: -
> ajax_support_event_listener: true
> ajax_manipulate_css: true
> displayHeight: 900
> is_tablet: false
> inputDevices: -
> ajax_support_javascript: true
> is_wireless_device: false
> ajax_manipulate_dom: true
> xhtml_format_as_css_property: false
>
> running the console demo or any comparable Java client app against a local
> Windows 7.
> So "is_crawler" or even a new "pixel_density" which might be of relevance
> to Retina screens, could be a nice extra gimick but a default display of
> 1600x900 is meaningless for a desktop and
> http://www.useragentstring.com/index.php tells me this
>
> Chrome 36.0.1985.125MozillaMozillaProductSlice. Claims to be a Mozilla
> based user agent, which is only true for Gecko browsers like Firefox and
> Netscape. For all other user agents it means 'Mozilla-compatible'. In
> modern browsers, this is only used for historical reasons. It has no real
> meaning anymore5.0Mozilla versionWindows NT 6.1Operating System:
> [image: icon] Windows 7
> <http://www.microsoft.com/windows/windows-7/>WOW64(Windows-On-Windows
> 64-bit) A 32-bit application is running on a 64-bit processorAppleWebKitThe
> Web Kit provides a set of core classes to display web content in windows
> 537.36Web Kit buildKHTMLOpen Source HTML layout engine developed by the KDE
> projectlike Geckolike Gecko...Chrome <http://www.google.com/chrome>Name :
> Chrome <http://www.google.com/chrome>36.0.1985.125Chrome
> <http://www.google.com/chrome> versionSafariBased on Safari537.36
>
> based on the same UA: Mozilla/5.0 (Windows NT 6.1; WOW64)
> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.125 Safari/537.36
>
> So we are far from that I'm afraid,
> Whether it's the hierarchy, that is rather likely something not only to be
> fixed or introduced for Firefox OS.
>
> I added an initial "genericFirefoxOS", feel free to experiment with
> extensions to that. As of now I didn't add a child device that would detect
> say:
> Mozilla/5.0 (Mobile; rv:14.0) Gecko/14.0 Firefox/14.0
>
> Werner
>
>
> On Wed, Jul 30, 2014 at 1:59 AM, eberhard speer jr. <[email protected]>
> wrote:
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Hey guys,
> >
> > can you please "hold your horses" for a minute ?
> >
> > I think we all agree a review of the Vocabulary is in order -- for
> > example -- but 'quickly' adding "is_somethingOrOther" to a 'patch'
> > file and mentioning it in JIRA does not strike me as proper.
> >
> > And I think the same goes for 'quickly' turning this, that and the
> > other into a "Factory" and adding a 'this' and a 'that' left, right
> > and center to the API.
> >
> > It seems to me that after the recent votes, we should take stock of
> > the situation, agree on what's next and *then* do the next thing.
> >
> > esjr
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v2.0.22 (MingW32)
> > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> >
> > iQEcBAEBAgAGBQJT2DV8AAoJEOxywXcFLKYcYwsH/RdIh7MmDONA9J0/CeSpES+B
> > iEcK235gz+YkJtV7pmm/XhMsRs4CDAYBIqpCNik7DR7Im1PAdgElSEliXc/4uQoQ
> > vWIBXqpb/KyVab8Q74GX9obHezAIOBGZW/+ZCWcmuNceCSLYBiA5DT5Ym0nyC6+Q
> > 4cRL1iQtfdewaAWblijEQG80QV0bfBBVhycHR0FZB1a8i+IXyQTcltP9LnngGy4L
> > +wk8FkbdvnE9LftezvpZQz4Z9dxf+8n1Q7+T1zS9s82Q93EmrpClVveEbv6/emBN
> > byayrXInTksgDiLRTx5ZFYq5W4AofxBTfue0/9MJ24uQKzoa5TKqjM2BpVePCZA=
> > =Fsfe
> > -----END PGP SIGNATURE-----
> >
>
