- From: Marcos Caceres <w3c@marcosc.com>
- Date: Sat, 24 Dec 2011 10:37:43 +0000
- To: liam@w3.org
- Cc: Noah Mendelsohn <nrm@arcanedomain.com>, "Martin J." <duerst@it.aoyama.ac.jp>, Jim Melton <jim.melton@oracle.com>, Bert Bos <bert@w3.org>, Julian Reschke <julian.reschke@gmx.de>, chairs@w3.org, "spec-prod@w3.org" <spec-prod@w3.org>
On Saturday, 24 December 2011 at 04:16, Liam R E Quin wrote: > On Fri, 2011-12-23 at 18:41 +0000, Marcos Caceres wrote: > [...] > > As an example, there is no guarantee that "xmldig-core1" will > > eventually (when it goes to Rec) replace "xmldig-core". I would like > > that guarantee. > > > > You can't have it. > > Sometimes the new spec supplants the old and sometimes not. But for cases where it does not break backwards compatibility, then I should be able to have it. It's the same with namespaces: you don't version namespaces (that would be stupid): you only mint a new one in the extreme case where you break backwards compat. Groups like XML Dig Sig acknowledge that in their spec [1]: "No provision is made for an explicit version number in this syntax. If a future version is needed, it will use a different namespace." So why not do the same for specs? > For example, sometimes we publish a spec and the community by and large > rejects it; XML 1.1 was an example. That's a good example actually. Except, it generally excepted that XML 1.1 is no backwards compatible with 1.0, hence: <?xml version="1.1"?> is explicitly needed to trigger it. So that would go into it's own short name (xml11), as it currently does. > We have to deal with the world as it is, not with the world as we'd like > it to be :-) The w3c isn't the world: we made the w3c that way, which means that we can change it. Please, lets keep a "can do" attitude ;) [1] http://www.w3.org/TR/xmldsig-core/#sec-Versions
Received on Saturday, 24 December 2011 10:38:15 UTC