[rfc-i] On backwards compatibility for v2
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
*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