W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > January 2010

[Bug 8357] Possible Compromise solution for namespaces in HTML5

From: <bugzilla@wiggum.w3.org>
Date: Fri, 08 Jan 2010 22:00:34 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1NTMsk-0003Tm-Gr@wiggum.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8357


Rob Ennals <robert.ennals@intel.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
           Priority|P3                          |P5
         Resolution|NEEDSINFO                   |




--- Comment #2 from Rob Ennals <robert.ennals@intel.com>  2010-01-08 22:00:34 ---
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


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Friday, 8 January 2010 22:00:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:09 UTC