Re: Syntax of new constraint proposal

On Mon, May 19, 2014 at 8:00 PM, Harald Alvestrand <harald@alvestrand.no> wrote:
> 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)

Yes, the way I read it, it was supposed to be an alternative but
equivalent way of specifying advanced constraints.

>, 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.

Apologies - I didn't know I stepped into a hornet's nest. I'll happily
write a JS shim to make the interface simpler and accept whatever our
syntax will be.

>>> 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.

I saw the large number of syntax proposals flying by. I just spoke up
when I saw a nice and simple one for the first time. It's ok if this
is too late - I can live with it.

Cheers,
Silvia.

Received on Monday, 19 May 2014 12:08:45 UTC