- From: Maciej Stachowiak <mjs@apple.com>
- Date: Mon, 12 Oct 2009 03:29:32 -0700
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Henri Sivonen <hsivonen@iki.fi>, Manu Sporny <msporny@digitalbazaar.com>, HTMLWG WG <public-html@w3.org>
On Oct 12, 2009, at 3:17 AM, Julian Reschke wrote: > Maciej Stachowiak wrote: >> ... >>> We're back at the Distributed Extensibility discussion. >> In any case, document-scope versioning is not a substitute for >> distributed extensibility. If two extensions to HTML use >> conflicting syntax, then a document-scope version (or feature use) >> declaration will not enable you to use both in the same document. >> This is true even if the extensions are different incompatible >> versions of the same extension. >> ... > > That's true no matter what versioning/feature declaration mechanisms > exist. It's somewhat less true for subtree-scoped feature/version declaration. Arguably, subtree-scoped versioning could be considered a form of distributed extensibility. Though at that point, you need a way to avoid collisions in the extension names. > But the existence of these mechanisms at least allows to use > incompatible extensions in *different* documents. Only if you have a way to guarantee uniqueness of the extension identifier. If we can't trust extension designers to coordinate enough to use non-conflicting syntax, then can we trust them enough to make unique identifiers? If we can trust them enough to make unique identifiers, then couldn't we just propose a prefix convention for extension syntax that uses the unique identifiers? The proposed @version assumes that every extension will have a globally unique identifier. Also: is it really acceptable to ignore the use case of combining content from multiple sources in one document (feeds, mashups, user- generated content, etc)? That's the consequence of only caring about different extensions in different documents. It seems to me that a versioning mechanism which fails for this use case is not a good design. It's not like we are forced to do it that way by legacy - we're designing brand new mechanisms. Nothing stops us from getting that use case right. Regards, Maciej
Received on Monday, 12 October 2009 10:30:07 UTC