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

Tantek Ç elik tantek at cs.stanford.edu
Sun Mar 25 12:33:08 PST 2007


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

> In message <C2295B35.8AB62%tantek at cs.stanford.edu>, Tantek Çelik
> <tantek at cs.stanford.edu> writes
> 
>> On 3/23/07 8:54 AM, "Andy Mabbett" <andy at pigsonthewing.org.uk> wrote:
> 
>>>> 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
>>> interoperably implemented;
>> 
>> Your not being able to prove it is insufficient reason to not accept the
>> burden of proof.
> 
> I wasn't preferring to personal inability, but to logical impossibility.

In that case let's take the aspects one at a time.

1. Easily implementable.  This can be proven by implementing, easily.  That
sounds like a tautology, but it literally means that.  Build it, and note
how hard it was. If it was easy then proof has been completed.

2. Interoperably.  This is much more difficult as you allude.  Further
discussed below.


>> Rather, don't assume that you personally have to prove the proposal as such,
>> but ask for help.
> 
> I did. I asked:
> 
>       Can anyone foresee any problems with that?

Let me clarify, ask for help with demonstrating the implementability which
could prove (1), rather than or in addition to help with raising
problems/issues (though that can be helpful as well if such problems/issues
are based on real world examples).


>> 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.
> 
> We can never prove complete interoperability; we can only find cases
> failure to work interoperably.

Strictly speaking you are correct - it isn't possible to "prove" complete
interoperability, all you can do is find and fix failure cases.

It *is* possible to demonstrate some level of "reasonable" or "acceptable"
interoperability through the use of some number of test cases.  But even
that is not what I intended to ask for here.  "proving" interoperability is
too strong of a request, and test suites, though strongly desirable (and I
am strong proponent thereof), are also more than I intended to request in
this thread.

"Demonstrate some amount of" interoperability is more reasonable, especially
if common real world content cases are used to demonstrate the
interoperability.

I hope this clarification is useful. I have attempted to capture some of
these thoughts around burden of proof and
brainstorming/proposals/suggestions here to continue building our shared
community understanding:

 http://microformats.org/wiki/brainstorming

Thanks,

Tantek




More information about the microformats-dev mailing list