Re: Syntax of new constraint proposal

On 05/19/2014 09:07 AM, Silvia Pfeiffer wrote:
> On Mon, May 19, 2014 at 11:21 AM, Harald Alvestrand
> <harald@alvestrand.no> wrote:
>> On 05/19/2014 02:13 AM, Silvia Pfeiffer wrote:
>>> On Mon, May 19, 2014 at 4:31 AM, Cullen Jennings (fluffy)
>>> <fluffy@cisco.com> wrote:
>>>> On May 18, 2014, at 1:21 PM, Justin Uberti <juberti@google.com> wrote:
>>>>
>>>>> I think 'ideal' will make this less inscrutable, e.g.
>>>>>
>>>>> videoCfg = {
>>>>>  require: ["width"],
>>>>>  width: { min: 640, ideal: 1920 },
>>>>> };
>>>>>
>>>>> which to me reads even more cleanly that the mandatory/optional syntax.
>>>>>
>>>> yah, that is even clearer - but the require things is still confusing. What about
>>>>
>>>> videoCfg = [
>>>>     { constrain: ”width”, min: 640, ideal: 1920 },
>>>> ];
>>> Or to express the same semantics as the first example, maybe:
>>> videoCfg = [
>>>     { constrain: ”width”, min: 640, ideal-min: 1920, ideal-max: 2560 },
>>> ];
>>>
>>> TBH I really quite like this. It turns the constraining around from
>>> listing the attributes, then listing the requirements, then the
>>> optional (but preferred ones) to grouping all information together by
>>> constraint feature.
>> Silvia, I have absolutely no idea what the semantics of the thing you
>> have just typed is, or how it would generalize to various combinations
>> that have been put forward as use cases.
>> Since this thread started off with "required", I have no idea how you
>> would express the difference between required stuff and non-required
>> stuff in that syntax.
> I interpreted the semantics of this proposal from Cullen:
> videoCfg = {
>  require: ["width"],
>  width: { min: 640 },
>  advanced: [
>     { width: { min: 1920 } },
>     { width: { max: 2560 } } ]
> };
>
> to mean:
> I want width to be a min of 640, but preferably between 1920 and 2560.
>
> Therefore my adjustment of his changed proposal to include the range
> of preference rather than a single "ideal" value.

In neither case are the semantics of "ideal" defined. Does it mean "I
prefer this precise value, if available" (same as an advanced
constraint), does it mean "I prefer values that tend towards this value
rather than the "natural" direction (presumably higher), but any value
in the range is OK", does it mean "take the square of all distances
between numerical values and their ideal values and run a simplex
algorithm to determine the lowest sum of squares"?

The point being that we need to have some common understanding of what
the proposal means before we can evaluate whether it is worth the cost
in implementor effort and cognitive effort on the part of users (the
spec developer effort matters too, but chiefly because of the time it
adds to our timeline - we're just a few people, unlike the users).

More suggestions without proposed defined semantics don't help with that.

>> But generally:
>>
>> I do NOT think this is a good time for coming up with more proposals.
> Take that up with Cullen, who started the thread.
> I personally wasn't aware that we had already changed the Syntax again, sorry.

Sorry, that came across a bit harsh. It was written on top of jetlag.
Cullen knows my opinions in some detail, since we've been talking about
it approximately once a week for the past 2 years - he's a spec editor.

I'm surprised you missed the syntax change - it's been a major topic of
discussion for the last 3 months on the media capture list. And it was a
very contentious issue.



> Regards,
> Silvia.
>
>> If we need to change things again, we need to have a really good reason
>> for it.
>> "Prettier" is not a really good reason.
>>
>>
>>> Silvia.
>>>
>>
>> --
>> Surveillance is pervasive. Go Dark.
>>


-- 
Surveillance is pervasive. Go Dark.

Received on Monday, 19 May 2014 10:00:53 UTC