Re: Settings retrieval/application API Proposal (formerly: constraint modification API v3)

One of the requirements for a specification to move to Recommendation in the W3C is for interop testing to be completed on all the features.

Maybe this has already been addressed, but what does it mean to interop capabilities? 

Does it mean to simply be able to set and obtain back setting values? In that case whether or not face detection works at all is irrelevant, as the test is about whether the capability value can be set and obtained (not whether there is truly an implementation behind it or whether such implementations are consistent).

There are a number of arguments against considering the algorithms used to implement such capabilities, including the need for algorithm agility and IPR to mention two.

A way forward might be to consider how testing is to be done, and the  effort and approach needed.

regards, Frederick

Frederick Hirsch
Nokia



On Sep 11, 2012, at 5:52 PM, ext Josh Soref wrote:

> Giridhar wrote:
>> Regarding "do whatever the camera manufacturer thinks is appropriate for a
>> function with this name", we do have precedence for providing implementation
>> flexibility in the W3C. 
> 
>> For instance, the Geolocation API poses no detailed requirements on the underlying
>> platform as to how to interpret the setting enableHighAccuracy.
> 
> The Geolocation API is generally understood to be a pretty terrible API in a number of ways. Referencing it isn't a good start to any argument.
> 
> Another example of a crappy API is the DeviceOrientation API which was published by the same WG. It basically has ZERO interop.
> 
>> Maybe a more constructive way forward (as opposed to
>> dismissing what I've proposed summarily) would be to at least determine those
>> settings that would not derail the standardization effort significantly.
> 
> So, "face detection" is an interesting thing. However, while it /may/ be possible to get interop in the form of "returns a rectangle that may have a fuzzy face, or an animal, or a statue, or a sculpture, or something that isn't remotely like a face", I'm not quite sure we're likely to see better interop than that. And I'm really unsure we'd be able to get interop on "how much padding will be included in the detected face boundaries".
> 
> An interesting question is can a face region have multiple faces?
> Would it be legal to return the entire picture's dimensions (for the case of a family/team picture, as opposed to an actual badge-photo)?
> 
> Calling those QoI distinctions is pretty problematic. If half of the implementations do it one way, and the other half does it the other way, you really don't have interop, and Cordova/jQuery and similar groups will be forced to just write their own shims which do detection they want manually (and more accurately). By that point, we've just mandated implementing something that doesn't work (and does add security/stability risks) and won't be used.
> 
>> boolean geotagging;// Default is false; true setting may be ignored if UA doesn't support.  Note that if UA does not support JPEG then this feature is disabled.
> 
> If the UA supports TIFF instead of JPEG, then I'd expect the tags to be available.
> I'd also expect the tags to just be available from the interface, in case I'm using PNG and just want to read the tags straight from the system instead of out of the image.
> 
> I'm also pretty sure that the part of speech for your boolean is wrong. "includeGeotags" or similar is probably better.
> 
> There's a similar risk for geotagging. I'd actually prefer that the geotag be specified as "include a location coord with precision indicator", this is distinct from features I've seen elsewhere where such coords are also converted to supposedly human readable strings (but which may be in all sorts of random languages, with misspellings and other amusing errors -- this is based on my work @nokia on the n900).
> 
>> boolean highDynamicRange;// Default is false; true setting may be 
>> ignored if UA doesn't support
> 
> Similarly, I'd expect "captureHDR" or "useHDR" or something. 
> 
> Personally, on the subject of how things should be shaped, I suspect I'd rather a single object attribute for a set of related things:
> 
> Interface FloatMinMaxCurrentValue {
> float value;
> float min;
> float max;
> }
> 	
> Interface SharpnessConstraints {
> FloatMinMaxCurrentValue sharpness;
> }
> 
> Interface RotationConstraints {
> FloatMinMaxCurrentValue rotation;
> }
> 
> Interface BrightnessConstraints {
> FloatMinMaxCurrentValue brightness;
> }
> PictureInfo implements SharpnessConstraints;
> PictureInfo implements RotationConstraints;
> PictureInfo implements BrightnessConstraints;
> 
> One advantage of this, is that people are much less likely to misspell things.
> I'm speaking as someone who just spent a week cursing a dozen groups for not being able to spell words (jQuery: Suppress has two p's, WAI: labeled does not have doubled L's, qunit: grr, jasmine: grr, ...).
> 
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
>

Received on Thursday, 13 September 2012 13:45:49 UTC