-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Stefano,
Interesting comment : "UAProf data is frequently unreliable". I assumed that the UAProf was the starting point for the data in the resources and I think that a reference to that source is vital exactly because it goes to the question of reliability. This is precisely the issue I wanted to raise : what is the source of the data and how is one to assess it's reliability. It is not that I have doubts about the reliability of the data (how could I), it is that I want to know what the source is and I want to be able to respond to the often heard comment : Yes, but X says that's wrong and that the data is unreliable. Having the UAProf to some point effectively addresses the issue : if the 'industry standard' data published by the OEM/Vendor is unreliable (how do we know ?) what is "reliable" ? I personally have frequently been confronted with this : "your" data says XYZ, I think that's wrong because so-and-so says it should be QRS. My 'standard' response to that is exactly to refer to the UAProf and some data item in it that is demonstrably wrong. The point being : the reliability of all data can be questioned sometimes with good cause, sometimes not. The question is : what is going to be the 'benchmark' to compare against and the UAProf, given it's presumed authoritative source. i.e. the OEM/Vendor, serves that purpose perfectly even if and particularly because it too is unreliable. So, to answer your question : the use case : a bit of *vital* 'academic sophistry' when the question of reliability rears it's ugly head and a reference to the 'authoritative industry standard' 'benchmark' source even if it may not the the source of the DMAP resources. Apart from that and also *very* important, having the UAProf would allow to add properties to the data set which are currently not covered in DMAP, even if this 'authoritative' source is not 100% reliable. Including a reference to this albeit poorly implemented and flawed industry standard -- see also W3C's DDR API -- seems evident to me. Kind Regards, esjr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRHyU4AAoJEOxywXcFLKYcyk4H/0OfewyrEh96xBZm4z2QGdcC PcsOq/qLJKH8Z4J0kRQUSWCMRlRDEF9MFzsWZd7J35lDUw60s/6jzJUTrl9HIolU Y9iyLQQzy+PEvoX0Ep59qcpy+UObatJsXDXKjVkzA+Lsk8neZcfkdkwItkBkhsuc mbk6ZxPIOPJ0EoinFlwFN14MLANI0Pqe8WSfB20aax0d7QcdNtKDIxMAPO8jjCYh CezSBNIberSe/wOZTf8o88JUdChw6WIKm9bul+nGvtaU6dzsXhgb5xzWPphLfF6T /872JAorGPRy9O5VPNFjcCSnuu0yEpQ98Iw2Y97weEQW4crrqM6b4/6of6EtXc4= =Du1V -----END PGP SIGNATURE-----
