Hi,
As Bertrand kindly preserved the last "WURFL Dinosaur" before its
extinction from a license meteorite, feel free to have a brief look at its
prehistoric information:
https://raw.githubusercontent.com/bdelacretaz/wurfl/master/2011-04-24-wurfl.xml
And a "patch" which you'll find exactly where the "WURFL service" takes its
information if you browse the site and test it:
https://github.com/bdelacretaz/wurfl/blob/master/2011-04-24-web_browsers_patch.xml
The tags contain all sorts of information, most of it (you even see the
keyword "OMA" a lot) gathered by the OMA consortium. They no longer seem to
do that, but both extended definitions like "is_wireless" etc. arise from
OMA and WURFL simply stole it or locked it away without the consent of
original contributors.
OpenDDR corrected most of those mistakes, especially by applying the W3C
DDR structure to the greatest possible extent. So people who contributed to
the former WURFL Open Source project can continue to to so in a proper Open
Source project. Hence some of the (OMA, not Passoni or ScientiMobilie
defined[?]) terms like "is_tablet" and especially the whole "nokia_series"
and other attributes were preserved to keep them compatible with the OMA
sources.
A thing you find in those WURFL files that is closest to DDR standard
"aspect" is the so called "group", like
<group id="display">
<capability name="resolution_width"
value="800"/>
<capability name="resolution_height"
value="600"/>
</group>
Note, neither the term "capability" nor the names like "resolution_width"
or "resolution_height" are anywhere near a standard. We fixed that as W3C
DDR clearly calls them "displayWidth" or "displayHeight". A few of the
other semi-standard ones defined by OMA and other participants.
The value of DDR especially for M2M, IoT and Embedded or Automotive was
mentioned a few times, here's what Blackberry (also bigger in Automotive
now than handheld phones) said about these:
http://global.blackberry.com/content/dam/blackBerry/pdf/business/english/telemetry/BlackBerry-M2M-Solutions_White%20Paper_Protocols-for-Device-Management-Software-Updates_A4_June-2013.pdf
Here's a related API which shows where WURFL "borrowed" the term
"capability" from;-)
http://www.gsma.com/oneapi/device-capability-restful-api/
So WURFL always was a hermaphrodite between device management and
detection, primarily driven by OMA, occasionally borrowing other terms they
picked up from W3C but never compatible to any of these standards. Nor is
it now, when it claims to "own" all the stuff it once gathered like ragmen.
Note, this W3C document co-authored by Facebook's James Pearce
http://www.w3.org/TR/2007/NOTE-dd-landscape-20071031/#sec-device is quite
clear, that EVERYTHING is a "device", but a "desktop" won't be a "mobile
device". We should respect the W3C standards and recommendations in this
context, too.
Aspect http://www.w3.org/TR/DDR-Simple-API/#aspect is fairly fuzzy, but
none of the actual repositories that are compatible with these specs use it
for e.g. an entirely different file or data structure. Where this was added
by OpenDDR, you may apply general attributes like "vendor" there in
addition to the "device" or "webBrowser" aspects and files.
However, unlike "vendor=Microsoft" for an OS the version makes no sense in
the OS aspect, but only with a particular device or browser.
Werner
On Fri, Aug 1, 2014 at 7:12 AM, eberhard speer jr. <[email protected]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> I known that some of what follows may be obvious and 'old news' to
> most of us, but just to be clear, *please* bear with me.
>
> When a client makes an HTTP request there are 3 ways to get the
> client's properties and capabilities :
>
> 1) Client probe : if supported, using javascript, query the
> 'navigator' object and other APIs. You basically 'ask' the client.
> This will get you a pretty accurate picture of the accessible
> properties. I say "pretty accurate" because UserAgents have been known
> to lie. [Yes, I'm looking at you Apple.]
>
> 2) DDR : here one or more signature n-grams from the UserAgent string
> 'map' to a 'static' record-set of properties and values. The
> properties are separate from the UserAgent and can include properties
> not available via probe [supported communication protocols for
> example] or not present, 'encoded' or otherwise, in the ua-string itself.
>
> 3) Parse UserAgent : here, usually using heavy regex-voodoo,
> information is extracted and 'deduced' from the UserAgent string.
> For example : if you run into "WoW" in an ua-string, you're most
> likely looking at Windows-on-Windows : a 32-bit UserAgent running on
> some 64-bit version of Windows, the rest of the string will probably
> tell you which Windows version.
>
> It is *very* important to observe here that although methods 2 and 3
> are fundamentally different, DeviceMapClient can do both !
>
> Also, methods 1, 2, 3 may and often will return different results for
> the same client and mostly with good reason.
> For example, if method 3 reports browser version 2.5 while method 2
> claims it's version 1.0, this does not mean the DDR is wrong. It much
> more likely means the device's browser was upgraded -- an important
> fact in itself, by the way.
>
> Now, with regard to Desktop.
>
> It seems obvious to me that applying method 2 to a Desktop is not
> meaningful. You can not have a meaningful 'static' record-set with
> non-fluff/default data for a Device with id "desktop".
> *But*, the same DeviceMapClient can do 'method 3' and return
> meaningful values, using the same property names as in method 2 [maybe
> others too like RenderingEngine].
> It's just a question of creating the right resources -- I fully agree
> with Reza there -- and *not* expecting method 3 to return 'default' or
> other properties specific to method 2.
> [that, and extracting the exact version numbers from the ua-string]
>
> Main point : let's not force method 3 cases like desktops into the
> method 2 straight-jacket and end up sending out meaningless 'default'
> data and properties that do not apply.
>
> DeviceMap can do both with ease ! The resources are key !
>
> Finally : I fully expect that with time many method 2 Devices will
> become method 3 'desktop' cases and that new device types and
> properties will appear in method 2.
>
> esjr
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJT2yG6AAoJEOxywXcFLKYckuEIAIjIIrSQSYiccdwt31PypNeV
> OPMDTJOXdwX7VH4p68nTKPk+jByUeJxaC/KRt5HKgfd/da4qUsAXM0NMZ5gD1Wyt
> Gzbi6fQ8H3+ejNVSGFtPJcH0Vg8K7axTCc3uYNnA1IL9BqC4NCVZLRgC4PHf5nXa
> 2dLjXVwVTODXvDkF2sjEOeD0jTa7mYiWizrqAQlfW2LojK9Xw4sEttlffPPspSmU
> uiXdLfcQgpRjUD9YakinsOpoNnCXpoqVtfQ3DN/B9C94mdXmYf5zycuFAGYeYL6b
> bTMfoj9YJdawp0kTdMPmuSo8FcU3SNFcj4dl0VGkT3gAJ074psbxd049eeKFkLk=
> =+GrW
> -----END PGP SIGNATURE-----
>
