[Fwd: Why chameleon use of namespaces is bad [ACTION-439]]

Forwarding an email message I wrote in 2006, for the public record.

-David

-- 
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/

Forwarded message 1

  • From: L. David Baron <dbaron@dbaron.org>
  • Date: Thu, 2 Feb 2006 08:43:25 +1100
  • Subject: Why chameleon use of namespaces is bad [ACTION-439]
  • To: member-cdf@w3.org
  • Message-ID: <20060201214325.GA23497@ridley.dbaron.org>
Here's some draft text on why importing identical elements into a new
namespace is bad.

-David

=====

Specifications should not import an existing vocabulary into a new
namespace (often known as chameleon namespaces), whether it is to use
one technology within another or to import elements from a previous
version of a specification into a new version.  This creates problems
for both authors and implementors when multiple namespaces import the
same vocabulary:

1. When authors or implementors building on W3C technologies want to
   search for, select, or match a certain type of element, having that
   same element appear in multiple namespaces makes the necessary code
   more complicated.  For example, use of DOM's
   Document::getElementsByTagNameNS [1], CSS element type selectors [2],
   or XPath's name test [3] all become more complicated when searching
   for the same element name within a set of namespaces, such as
   searching for an XForms input element [4] within the XForms an XHTML2
   namespaces.

2. Implementors are likely to face the same cost within their
   implementations:  when they support multiple imports of the same
   vocabulary, the question of determining whether an element is a
   certain element type in that vocabulary becomes more complex to
   write.  Furthermore, because it is more complex to write, it will
   be done incorrectly more often, leading to bugs that appear only when
   the vocabulary is used within some of the namespaces into which it is
   imported.

3. Implementations are likely to face extra complexity and users of W3C
   technologies are likely to deal with extra confusion because of
   ambiguity over what DOM interfaces are implemented by imported
   elements.  Implementing SMIL Animation elements such that they
   implement the SVGElement interface only some of the time can be hard
   for implementors; authors likewise might come to expect that SMIL
   Animation elements implement SVGElement when this is only true when
   those elements are imported into the SVG vocabulary [5].  (This issue
   is slightly less general than the others; it only applies when
   specialized DOM APIs are involved, and it only applies for importing
   of another technology rather than importing as a versioning
   mechanism.)

[1] http://www.w3.org/TR/REC-DOM-Level-3-Core-20040407/core.html#ID-getElBTNNS
[2] http://www.w3.org/TR/CR-css3-selectors-20011113/#type-selectors
[3] http://www.w3.org/TR/REC-xpath-19991116.html#NT-NameTest
[4] http://www.w3.org/TR/REC-xforms-20031014/slice8.html#ui-input
[5] http://www.w3.org/TR/REC-SVG11-20030114/animate.html#RelationshipToSMILAnimation
    http://www.w3.org/TR/REC-SVG11-20030114/animate.html#InterfaceSVGAnimationElement

-- 
L. David Baron                                <URL: http://dbaron.org/ >
           Technical Lead, Layout & CSS, Mozilla Corporation

Received on Tuesday, 17 February 2009 00:34:45 UTC