Re: If we have versioning, it should be in an attribute, not the doctype

On Tuesday 2007-04-17 20:57 -0400, Murray Maloney wrote:
> Seems to me that a namespace declaration on the root element would do the 
> trick.
> That would be in keeping with Web Architecture and available tools.
> Why not a namespace?

To quote from something I wrote last year [6] about importing
vocabularies into new namespaces (whether to use one technology
within another or import elements from a previous version 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.)

-David

[1] http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#ID-getElBTNNS
[2] http://www.w3.org/TR/2001/CR-css3-selectors-20011113/#type-selectors
[3] http://www.w3.org/TR/1999/REC-xpath-19991116.html#NT-NameTest
[4] http://www.w3.org/TR/2003/REC-xforms-20031014/slice8.html#ui-input
[5] http://www.w3.org/TR/2003/REC-SVG11-20030114/animate.html#RelationshipToSMILAnimation
    http://www.w3.org/TR/2003/REC-SVG11-20030114/animate.html#InterfaceSVGAnimationElement
[6] http://lists.w3.org/Archives/Member/member-cdf/2006Feb/0009

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