Re: making interoperability decisions (was Re: parsing URI (references) according to RFC 3986)

On Mon, Jun 20, 2011 at 1:19 AM, "Martin J. Dürst"
<duerst@it.aoyama.ac.jp> wrote:
> Hello Chris, others,
>
> On 2011/06/20 13:51, Adam Barth wrote:
>>
>> On Sun, Jun 19, 2011 at 9:35 PM, Chris Weber<chris@lookout.net>  wrote:
>
>>> Regarding interoperability decisions - has consensus previously been made
>>> among the WG members as to how a behavior-difference should be resolved?
>
> Not that I know. I think we haven't actually had any specific decisions
> made, so we couldn't even point to examples. But it's good to see that you
> as a chair are asking these kinds of questions. I'd not want to have
> complicated rules, but having a discussion about the considerations involved
> is a good thing.
>
>>> In
>>> a case like treating a "\" as a "/", would the most reasonable decision
>>> be
>>> based on how many of the 5 most popular Web browsers are doing it, or
>>> would
>>> it be based on market share, or something else?
>>>
>>> For example, if only IE and Firefox treated "\" as "/", would that be
>>> reason
>>> to write such behavior into the spec?  (considering those two together
>>> claim
>>>>
>>>> 50% total market share).  Or what if the case was Opera, Safari, and
>>>
>>> Chrome - 3 out of the 5 but still<  50% combined market share.
>
> I personally would agree that number of browsers (there are others than the
> five that are usually mentioned) and market share should be something to
> consider. But we shouldn't make decisions based on these numbers if it's a
> close call (e.g. 51% vs. 49%, or even a bit more slanted).
>
>> There isn't really a general rule for how we make these sorts of
>> decisions.
>
> Agreed. As a WG, we can adopt rules, but then we can also break them.
>
>> Usually there are a number of factors involved.  For
>> example, having 4 of 5 browsers implementing one behavior can be a
>> strong indication that we should change the spec and the 5th browser
>> to converge with that behavior.  Another consideration might be
>> whether one behavior is likely to be more compatible.
>
> Compatible with what? We might want to look at compatibility with existing
> content (but then this is rather difficult, because it's usually not a
> question of 50% or more, but a question of 0.1% or 0.001%, and the data may
> vary very much depending on the sample).
>
> Or compatibility with the current specs (which means compatibility with
> people who implemented from spec, which seems to be the case a lot in areas
> besides browsers). I'd personally hope that we can give this some
> non-negligible weight.

When I say "compatibility" I almost always mean "compatibility with
existing content on the web."  It is hard to measure, which is what
makes many of these decisions tricky.  Usually we aim for between four
and five "nines" of compatibility, which means roughly 99.99-99.999%
compatibility.  Sometimes that's impossible, for example when there
are two mutually exclusive decisions that each have compatibility
costs.  In those cases, we generally main for the less of two evils.

Compatibility with current specs (aka, compliance) is certainly a
"nice to have," but usually successful specs influence decisions by
way of interoperability interest with implementations of those specs
or by way of compatibility concerns with content that relies on the
specs.  In the ideal case, when standards bodies and implementations
do a good job, all three align and everyone is happy.

The priority of concerns is essentially:

compatibility > interoperability > compliance

Adam


>> In this case, it seems fairly clear that we should treat \ like / for
>> at least some common schemes.  The real test, of course, is whether
>> Firefox actually adopts that behavior.  To make progress on these
>> sorts of issues, we need folks "in the room" who can commit to
>> implementing whatever decision we reach.  In some sense, that's more
>> important than the particular details of the decisions we make.
>
> We seem to get closer to this, finally. Great!
>
> Regards,   Martin.
>

Received on Monday, 20 June 2011 08:43:52 UTC