burden of proof (was Re: [uf-dev] Suggested new parsing rule for alt text)

[Tantek Ç elik]

On 3/23/07 8:54 AM, "Andy Mabbett" <andy at pigsonthewing.org.uk> wrote:

> In message <C2293C6B.8AB1B%tantek at cs.stanford.edu>, Tantek Çelik
> <tantek at cs.stanford.edu> writes
> 
>>> Your "very little benefit" is hypothetical and unfounded.
>> 
>> Andy, while I appreciate the swift calling of "hypothetical", you have
>> the burden of proof backwards.
>> 
>> The burden of proof is on any new parsing rules to demonstrate real
>> world benefits using real world examples, not on Brian nor anyone else
>> to "prove" very little benefit.
>> 
>> That is, new proposals/rules have "very little benefit" (and potential
>> cost), until proven otherwise (that they *have* a benefit,
> 
> I accept that. I thought my Wikipedia example provided such evidence -
> and my wider reference to CMSs a use case.
> 
>> and *can be* implemented easily and interoperably).
> 
> I don't accept that. I can't prove that something can be easily and
> interpretably implemented;

Your not being able to prove it is insufficient reason to not accept the
burden of proof.  

Rather, don't assume that you personally have to prove the proposal as such,
but ask for help.  Make it clear that you don't know if it can be
easily/interoperably implemented, and ask the dev list for help.  But accept
that until it is proven as such, there must be doubt, and note that in your
proposal.  

It is plenty fine to have proposals being considered with the doubts being
explicitly noted. In fact, it is *preferable* if those making proposals are
up front about about the doubts in their own proposals. It shows better
introspection.


> surely it is for other people to show (if
> indeed it is the case) that it cannot.

Similar to the burden of proof explanation above, it is not others'
responsibility to prove a negative.  The assumption is that something is
hard to implement and non-interoperable until proven otherwise by someone
actually easily building an implementation, and someone else building
another implementation that interoperates with the first.

Tantek