- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 12 Oct 2009 13:20:48 +0200
- To: Maciej Stachowiak <mjs@apple.com>
- CC: Henri Sivonen <hsivonen@iki.fi>, Manu Sporny <msporny@digitalbazaar.com>, HTMLWG WG <public-html@w3.org>
Maciej Stachowiak wrote: >> 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. URIs as extension names provide that. So should I make a proposal to allow @profile on any block-level argument (only semi-kidding). >> 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. ...thus would need a registry, it appears. > 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. > ... I agree that it would be good to solve this use case as well. BR, Julian
Received on Monday, 12 October 2009 11:21:23 UTC