Well in many cases the vendor of a "device" and desktop PCs or tablets can
be the same, see
<device id="Dell Streak 7" parentId="genericDell">
<property name="model" value="Streak 7"/>
<property name="displayWidth" value="480"/>
<property name="displayHeight" value="800"/>
<property name="mobile_browser" value="Android Webkit"/>
<property name="device_os" value="Android"/>
<property name="device_os_version" value="2.2"/>
<property name="dual_orientation" value="true"/>
<property name="is_tablet" value="true"/>
<property name="inputDevices" value="touchscreen"/>
<property name="ajax_support_javascript" value="true"/>
<property name="ajax_support_getelementbyid" value="true"/>
<property name="ajax_support_inner_html" value="true"/>
<property name="ajax_manipulate_dom" value="true"/>
<property name="ajax_manipulate_css" value="true"/>
<property name="ajax_support_events" value="true"/>
<property name="ajax_support_event_listener" value="true"/>
<property name="image_inlining" value="true"/>
<property name="from" value="open_db_modified"/>
</device>
The OS is "Android" here, while a destop PC often has "Windows" as OS, it
may of course be Linux, or another UX,
There's only Apple in the O
Even a "genericDesktop" must be version-independent, so adding more to
OperatingSystemDataSource than just Apple is worth exploring.
The DDR Simple API contains an OS object, but much more than a vendor of
that OS (with Linux the "Distributor" is sometimes more important than the
vendor, even Android has flavors by Samsung, Amazon or others[?]) won't make
sense there. Regardless of the property name, os_version belongs to the
device, as it differs from device to device.
Actually the OS can be upgraded in some cases, so the shipping OS could be
different from the actual one, but the "device_os_version" see above shall
be considered as the one it's shipped with. If the UA would allow to
override that with a more precise actual version, sure, but an OS
definition likely won't be up to date with service packs or fixes either.
Windows 7 looks like "6.1.7601" but the last part is more or less a build,
could increase over time, so "6.1" or similar might tell us it's "Windows
7".
Werner
On Fri, Aug 1, 2014 at 12:17 AM, Reza <[email protected]>
wrote:
> Actually, Eberhard brings up a good point. I thought about it more on the
> way home tonite and I think we are going down a slippery slope by pseudo
> combining device and OS detection.
>
> So currently, a user agent tells us 3 key things:
>
> -device type
> -OS
> -browser
>
> examples:
>
> desktop, ubuntu, chrome
> desktop, macintosh, safari
> galaxy 4, android, firefox mobile
>
> So those attributes are all technically independent. However, for phones,
> the OS is an attribute of the device which is probably why we are expecting
> OS and device to be hand in hand. This is not true, its not true for
> desktops, and as time goes on, we may see devices running different OSes...
> maybe...
>
> So a desktop is not a device. But we can infer it using the patterns.
> Direct detection includes detecting the OS (windows nt, macintosh, ubuntu)
> which tells us its a desktop or just looking for generic desktop browser
> patterns and the lack of a device pattern. This is why its possible to
> combine device and OS classification (and browser classification). But I
> dont think its a good idea.
>
> Example, is detecting a device as a genericDesktop correct or incorrect?
> What value does an appleDesktop have over a genericDesktop? We should be
> detecting the device type and the OS independently. That means we have a
> desktop running Macintosh (which is developed by Apple) or we have a
> desktop running windows, or we have a desktop and its running an unknown OS.
>
> Once we breakout OS into its own classification, then appleDesktop (or
> windowsDesktop) becomes redundant and possibly misleading because our OS
> attributes are in both the device and OS. I think this sums up Eberhard's
> point :)
>
> Secondly, the patterns are different for both of these classifications. So
> while its possible to combine the 2 for desktops and most phones, these
> pattern indexes are better kept separate. This will keep the concerns
> seperate and allow both patterns to be more direct in "finding their
> target".
>
> Another example of this is classifying a device as genericAndroid... maybe
> its better to say its an unknown device running the android OS. But here an
> android OS tells us a lot about the device in a generic way, so its kind of
> a gray area.
>
> Food for thought :)
>
>
> ________________________________
> From: Werner Keil <[email protected]>
> To: "[email protected]" <
> [email protected]>
> Sent: Thursday, July 31, 2014 5:14 PM
> Subject: Re: generic desktops, crawler, and generic android
>
>
>
> Aspect is not new or unique to OpenDDR but defined by W3C DDR, see:
> http://www.maddr.org/ddrsimpleapi
>
>
> An aspect allows to group certain properties together, but their semantic
> meaning.
> So "vendor" in the Device aspect is just the same as "vendor" in the OS
> aspect, which is why additional values like "osvendor" or "os_vendor" (that
> is just a different way of calling it in non-core vocabularies) can be
> necessary.
>
> "Microsoft" works as "osvendor" but especially for a desktop computer the
> "vendor" should be blank unless you want to specify particular PCs by
> vendors like "Lenovo", "Acer" or "Dell"
>
> Werner
>
>
>
>
>
> On Thu, Jul 31, 2014 at 10:39 PM, eberhard speer jr. <[email protected]>
> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> >Hash: SHA1
> >
> >Color me confused, but wasn't there such a thing as 'Aspect' in the
> >various standards ?
> >To whit, the W3C DDR Aspects : Device, Browser, OS.
> >
> >So Aspect qualifies Property, as in : Device Vendor, Browser Vendor
> >and OS vendor...
> >
> >If that's the case "os_vendor" is a travesty at best.
> >
> >esjr
> >
> >
> >
> >
> >On 31/07/2014 23:22, Werner Keil wrote:
> >> If we want to properly use a a value like "Microsoft", then adding
> >> "osvendor" instead of "vendor" for that could be a first step. If
> >> streamlining with OMA or similar standards is in the interest of
> >> downstream projects, that would be the next step. Either for a
> >> pending "1.0.1" update of the data artifacts in the near future or
> >> for one beyond.
> >>
> >> Werner
> >>
> >> On Thu, Jul 31, 2014 at 9:50 PM, eberhard speer jr.
> >> <[email protected]> wrote:
> >>
> >
> >> About the 'default', to be clear :
> >>
> >> I am referring to any value that is empty, '-', 0 [meaning no
> >> value] and any property/value that represents a 'default' value.
> >> Not only the properties that are 'meaningless' like nokia_version
> >> for a desktop.
> >>
> >> Adding these generic 'defaults' may look impressive but the data
> >> is meaningless fluff. If the value for property xyz is not present,
> >> not known or is some known default [you can spot them], it should
> >> not be included in the response.
> >>
> >> That's an 'honest' response, in that the end-user now knows that
> >> any property not present can default to something meaningful in
> >> their current context, instead of having them 'run' with nonsense
> >> 'default' data.
> >>
> >> That's an honest and much shorter response : all signal.
> >>
> >> esjr
> >>>
> >>
> >
> >-----BEGIN PGP SIGNATURE-----
> >Version: GnuPG v2.0.22 (MingW32)
> >Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> >
> >iQEcBAEBAgAGBQJT2ql+AAoJEOxywXcFLKYcOfYIAKqkGN2kvF4kx+zMKhvbslvu
> >errQq9qqoxX1cXcpIvPwokv8NqDVS9iL4ufFzN25SnLflR6DuZHtlfwPp4bO2Krg
> >8JfD1kFS6jr3yAizxdwr2jWrN+SVaEpFOZalpTuECE+YSQErmO4WTJ3ieBq4hrEA
> >AhyAkQmNskObvsk564kqLatGo4Tw8FZhi4loLlGKpSk/XnnEPHNRceVzhtIoX8sQ
> >xWMyDk9p/X7/msIQZGrRLk16d2Yc8oraMbUrZqZxUGx9D2sGoi3Rt5WFG2UBL2M4
> >EdnQAGoMJ6aUIKBDejD3B9YALwUaLudGL/CLuW25wTIgkkwQZjGVhVsb/Qz4Twc=
> >=eEaS
> >-----END PGP SIGNATURE-----
> >
>
