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

Are you suggesting that these problems are too great a barrier?
I am willing to accept that answer, I am just looking for someone
to back you up.

Dan, is David correct on this? Do namespaces make HTML too difficult
to work with? Or is it all in how you look at it? Help me out here.


At 06:22 PM 4/17/2007 -0700, L. David Baron wrote:
>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

Received on Thursday, 19 April 2007 14:09:37 UTC