[rfc-i] On backwards compatibility for v2

Julian Reschke julian.reschke at gmx.de
Mon Feb 10 14:31:38 PST 2014


On 2014-02-10 23:15, Dave Crocker wrote:
> ...
>  > But the move from v1 to v2 has already shown us
>> that the even when the format isn't changing in major ways, different
>> tools may interpret it differently, and bugs may arise.
>
> Interoperability (compatibility) is difficult, so let's not try?
>
> But mostly I think your citing v1/v2 serves to show the problem of not
> making compatibility a core requirement.
> ...

v1->v2 was a tools change, not a vocabulary change.

v2->v3 will be a vocabulary change, but not necessarily a tool change (I 
hope we can just extend the processors we have).

A big part of the 1->v2 issues was caused by the TCL code not using an 
XML parser, thus accepting lots of junk. Hopefully this is now fixed by 
using a proper parser in the v2 tool.

>> This isn't something that can realistically be prevented without a
>> lot more developmental rigor than I anticipate.
>
> I'm not sure what sort of 'rigor' you think would be needed.
>
> But has anyone else noticed the irony of such easy dismissal of backward
> compatibility being made over the Internet and with email?
>
> At base, I think we're being quite cavalier about the actual costs of
> incompatibility.
> ...

Maybe.

*My* main reason for trying to be compatible is about something else 
though: once we decide that breaking things is OK, we'll likely have big 
vocabulary design debates that are common when designing new XML 
vocabularies, and there *will* be people showing up asking to switch to 
(X)HTML if we break things anyway. We can avoid all of this by adding a 
v2 compat constraint.

Best regards, Julian


More information about the rfc-interest mailing list