Re: Support Existing Content

On May 4, 2007, at 9:57 AM, Chris Wilson wrote:

> Maciej Stachowiak wrote:
>> On May 4, 2007, at 3:21 AM, Gareth Hay wrote:
>>> Why does there need to be a technical motivation behind my position.
>>
>> The job of working groups is to make technical decisions based on
>> facts and logic. If your position has no technical motivation, then I
>> do not see why others should consider it.
>
> The job of the Working Group is to come to a consensus  
> specification.  That consensus will include technical as well as  
> pragmatic reasoning in its motivations.

I don't understand the distinction you are trying to draw. Surely  
pragmatic reasoning is a form of technical reasoning based on  
particular facts. What I'm trying to exclude from consideration is  
reasons that have *no* fact-based motivation, just a feeling that  
something is good or bad.


>> That's because you refuse to state your reasoning. You're asserting
>> that nonconforming content, or tag soup, or invalid content, whatever
>> you want to call it, is harmful. But you haven't stated what the harm
>> is.
>
> I want to be clear I'm not taking a stance against (or for) tag  
> soup.  I will state that in my opinion, the harm of non-draconian  
> error handling is that it harms interoperability.  No matter how  
> precise we intend to be in the spec, I can guarantee that there  
> will be error cases that we do not cover or normatively specify,  
> and since Opera, Mozilla, Safari and IE do not share actual code  
> (or architecture), you can be pretty well guaranteed that there  
> will be differences that fall through the cracks.

I did mention interoperability problems as the one harm of  
nonconforming content that I acknowledged. Discussing whether that is  
the most effective way to address the interoperability issues is much  
more productive than an unsubstantiated assertion about what is good  
and what is bad. I think the best way to address it is through  
defining error handling.

> By comparison, a draconian error handling system reduces the scope  
> of what needs to be handled, to the scope of what is exactly  
> covered in the spec - effectively paving over those cracks.

I don't think this reasoning holds though - at best it can move the  
cracks. Instead of failing to implement an error recovery rule, a UA  
could fail to implement an error rejection rule, and if the UA  
happens to be reasonably popular we could once again have a lack of  
interoperability. Error rejection might be simpler to describe than  
error recovery, but it still leaves some room for error. Furthermore,  
a must-reject policy is an unstable equilibrium, as Henri Sivonen  
pointed out. If one UA mistakenly falls back on some error, ships,  
and content starts depending on it, then other UAs have a motive to  
emulate that error handling. And soon we are back to the ground zero  
of mutually reverse-engineered error handling. We've seen this to  
some extent already with RSS.

>> with end users being exposed to the effects of draconian error
>> handling, because problems haven't all been caught at the source and
>> solved.
>
> And this is where I agree with you - producers never catch all  
> their errors, and users exposed to errors is a bad thing.

I'm glad we agree on that.

Regards,
Maciej

Received on Friday, 4 May 2007 21:12:43 UTC