Compatibility with existing systems
Industries thrive on standards: interplay between companies using compatible technologies is proven to grow markets, enhance competition, and result in technical innovation and great strides in value.
Either no one told the Device Detection sector, or it just didn't listen.
Defeating Incompatibility and System Lock-in - the twin evils of device detection
DetectRight's decoupled data and device detection engines make it possible to deliver quality and choice to anyone using Device Detection, whether it be WURFL users, DeviceAtlas users, custom databases, followers of the W3C standards, or just people who want something simple that works.
Even the standards aren't standard
There are two official (and incompatible!) standards in the field of Device Data and Device Databases: the W3C Simple DDR API (and the associated W3C Basic Vocab), and the OMA CC/PP specification that resulted in UAProfiles.
Both have so far failed.
No one is more grateful that UAProfiles exist than people who run device databases, since without them (as we've found with many Androids and Apple) without that information, there is a lot that isn't released at all. In the days of yore, the question of "should we give anyone information about our devices" was a thorny one. Technical information released was assumed to be technical information that competitors would use against them. The lure of the dark side was strong. Given that, it's amazing there was any standard at all.
However, looking back to the process that created the UAProfile specification, it's almost quaint how it was envisaged to be used: as a machine to machine real-time exchange of capability information based on XML.
The presence of the UAProfile field "CurrentBearer" is witness to the failure of the standard, but there were three killers, which could have been foreseen in advance: in fact, you'd think that people would by now learn to make allowances, in the same way you'd expect economists to allow that people aren't rational decision makers. But they don't.
Here are the things which killed the original purpose of UAProfile:
- The Internet can be slow
- URLs die (we have stores of UAProfiles which are now not available on their original URL, though our UAProfile format composite datafiles for the devices is usually fuller and validated)
- People and companies are really bad at consistency, especially when there's no penalty for poor quality work, but every penalty for taking the time to get it right.
Thanks should go to the visionaries in companies such as Nokia, Samsung, Alcatel, ZTE, Kyocera, Motorola and the other companies who kept UAProfiles alive and who tried to make their own data consistent.
We think the ultimate fate of UAProfile is as a data import source, and as a supplier of extended fields: specifically as a safe vocab for extending the W3C basic schema, which by itself is very... well, basic.
Which brings us to the W3C DDR Basic API Standard
The original meeting in Madrid which took the DDWG (Device Description Working Group) down the route of defining a standard API for a device description repository was convened for a different purpose: to provide for a universal centralised free device data source. By the time it had finished, the vision was for a global ecosystem of device repositories for different purposes and with different specialties, based on an open API, and sharing a common vocabulary. A beautiful vision.
But what was realised bore very little resemblance to the vision.
The reference API was a Java API for a device detection repository, not an API for a device description repository (the API contains no specifications for exchanging device data and catalogues between systems).
The only reference API was a local deployment. Details of how data would be exchanged between remote systems was entirely absent, a startling omission.
Result: no take up
For various reasons, there was no long-lasting commercial take-up of the W3C standard, except for our own use of the W3C Basic Vocab, soon extended by DeviceAtlas. Initially DeviceAtlas (who were formed on the back of them) boasted of W3C support, and based their schema on the W3C Basic Vocab: but there was no buy-in from the other players in the sector, and active hostility from others.
It says a lot about the development of the standard that parts of it are now being deprecated by its only commercial adopter: apart from us. Our commitment to compatibility has been there since we were the first organisation in the world to deploy the W3C Basic standard. The response from the W3C? "It doesn't count, it's just a draft standard"
That pretty much says everything you need to know about the commitment of the device detection sector to genuine standards which actually help.
Our compatibility currently is at field level.
But, it was still a great vision: and it's our vision too.
But while we're developing that (see The Open Device Knowledge Collaborative for the seed), we're aiming to bring badly needed quality and choice to a sector plagued by a lack of choice, proprietary and patented outdated technology, and a complete lack of agreed standards for measuring anything it does.
Making a buying decision in our sector is far too dependent on vendor-hype, and not enough on objective data: unless the buyer does the tests themselves. Our white papers go some way towards fixing this, but there needs to be much more work on that.