This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
[This is the same message previously posted to public-html, now reported as a bugzilla bug.] [This proposal addresses HTML-WG-ISSUE-41 - distributed extensibility] Hi Guys, I'd like to propose a new compromise solution for allowing distributed extensibility and XML namespaces in HTML5. This proposal is based on conversations that I had with a lot of people at TPAC, and conversations that I had with other people subsequently. It shamelessly steals ideas from Liam's proposal and some of Tony Ross' ideas, but it's also a bit different. I should note that this is a proposal from me, not an official Intel corporate position. The basic idea is this: * An HTML5 document can contain tags and attributes that have prefixed names like "svg:bla". * A particular prefix always means the same thing, in any file. Thus e.g. "svg" always means SVG * A central registry records the meaning of all such prefixes, to prevent name clashes. The registry says what the namespace URL is, who registered it, what it does, and provides a link to a specification that would allow others to implement it. To appear in this registry, you are expected to publish a specification (not necessarily with the W3C), not be vendor specific, and be broadly useful * You can also use a prefix beginning with "x-" (e.g. x-fbml) to denote an unregistered, experimental, or proprietary extension. * A document can use a namespace declaration (e.g. xmlns:svg = "wibble") to bind a prefix to a namespace, but this MUST be the same namespace recorded in the registry for that prefix (except for an "x-" prefix). * A document is invalid if it contains multiple namespace declarations that bind the same prefix to different namespaces. * HTML5-specific tools will typically only look at the prefix, and ignore the namespace of the tag - since the xmlns declaration may be missing, and the correct namespace for the prefix is fixed. However the xmlns declaration must be present in order for the file to be a valid XML document. * There are three levels of HTML5 validation: - Valid Pure HTML5 - the document contains no prefixed tags other than svg and mathml. It is guaranteed to render correctly in all HTML5 browsers. - Valid Extended HTML5 with features X and Y - the document contains registered prefixes X and Y, used correctly, in accordance with their specs. The validator should ideally also tell you what each of these features means, and which tools support them (reading from the registry) - Valid HTML5 with proprietary extensions X and Y - warning that these are proprietary extensions that may not be widely supported This proposal has the following features: * It is compatible with existing XML namespaces * It allows polyglot files that are both valid XML and valid HTML, and which use extensions * It avoids confusions of namespace indirection, since a prefix always means the same thing. In particular, you can copy and paste code between arbitrary HTML files and it will always work. * It makes it explicit when a tag comes from an extended namespace, by requiring that it have a prefix - thus making it easy for an author to know that they are relying on extended features * It makes it explicit when a tag is using a proprietary extension that may not be well specified or supported * The validator makes it clear to a content author whether their file uses extensions that may not be supported in other browsers * It encourages the authors of extensions to publish a spec and let others know what they are doing * It doesn't require the parser to fetch an external file before it can parse a document * It allows independent parties to develop useful extensions without the W3C having to act as a choke point to approve stuff Apologies if someone has proposed this before. Thoughts? -Rob
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Did Not Understand Request Change Description: no spec change Rationale: To properly evaluate this proposal, I need a description of the problem that the proposal is solving. What is the problem that this addresses, and why are the existing extension mechanisms insufficient for that purpose?
This is a change proposal designed to address for ISSUE-41, which has already been adopted as an issue by the working group. The mails currently attached to ISSUE-41 contain a desciption of why some people consider the current mechanisms provided by HTML5 to be inadequate. In particular, many people believe that it is important that it be possible for multiple independent parties to experiment with extensions to HTML5 without the W3C acting as a chokepoint. While mechanisms such as microdata and class names allow one to describe the semantic meaning of page content, they do not allow people to create new kinds of visual content such as e.g. if MathML was not part of HTML5, it would not be possible for independent parties to add it. Moreover, even if we declare that such extensions are "bad" it is inevitable that people will produce their own extensions anyway, so it is best if we provide people with a mechanism that lets them develop extensions in a way that does not harm the larger ecosystem (by e.g. discouraging people from sticking new stuff in the global namespace, discouraging indirected namespaces, and requiring that a validator makes it clear when a user is using an extension). You have made some very valid points about why distributed extensibility can be harmful - since there is a danger of platform fragmentation, and people may produce bad specs if they don't talk to the working group first. However there is also a contrary argument that forcing all innovating to go through a central authority risks slowing down innovation. The best solution is probably some kind of middle ground. This is what this change proposal is aiming to do. -Rob
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Did Not Understand Request Change Description: no spec change Rationale: HTML, HTML2, HTML3.2, and HTML4 did not have extension mechanisms of this nature, and yet multiple independent parties have often experimented with extensions to HTML over the years. So it's not clear to me why we need anything to enable that. Could you elaborate further on why experiments (which presumably are not to be used in production projects) need to be conforming?
This is a proposed solution for ISSUE-41, which has already been accepted as an issue by the working group chairs, as part of the decision process. If you believe that ISSUE-41 is not a valid, issue, then shouldn't the correct procedure be to argue for the closing of ISSUE-41, rather than this bug?
That's not how the process works. Please see: http://dev.w3.org/html5/decision-policy/decision-policy.html
Ah yes. Looks like I shouldn't be filing this as a new bug, but as a proposal for ISSUE-41. I'm still getting the hang of the decision process. I'll hopefully be submitting a change proposal within a couple of weeks. I'm optimistic that we'll be able to find a solution that satisfies the key requirements of those who want distributed extensibility, while also meeting your very valid concerns about why it can be a bad idea if done the wrong way. -Rob