W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2004

DOM 3 Core namespace normalisation and Level 1 nodes

From: Andrew Clover <and-w3@doxdesk.com>
Date: Thu, 19 Feb 2004 12:31:36 +0000
To: www-dom@w3.org
Message-ID: <20040219123136.GB30090@doxdesk.com>

There's an issue with namespace normalisation in the reference algo
(B.1) in PR which I hadn't noticed until DOM-TS started testing for

    if ( Element's localName is null )
       // DOM Level 1 node
       Otherwise, report an error

I believe this behaviour to be undesirable. It would mean you'd be
unable to serialise any document containing Level 1 Elements
(or Attrs) without deliberately setting the DOMConfiguration
parameter 'namespaces' to false.

Previously Core has only warned that "mixing both sets of methods
can lead to unpredictable results"; this is the first time it has
been made an actual error. Though there are indeed cases where
mixing levels causes problems, there are also common trivial cases
which are unambiguous.

In my opinion, raising a warning may be appropriate, but making it
an error (so that by default processing stops altogether) seems
excessively harsh and likely to bite application authors a lot.
There are still times where it is useful for a function to, for
example, add an unprefixed attribute to an element without caring
whether the element is a Level 1 or 2 node.

I'm not sure namespace normalisation should be touching Level 1
nodes at all; perhaps it would make sense to raise an error only
for clearly namespace-ill-formed names (eg. 'blob::'). Don't know
if such a change is even possible at this late stage, but I thought
I should bring it up.

Oh, and on a completely unrelated issue, the resolution to issue
CR-andrew2 should be applied to setIdAttributeNode as well as
setIdAttribute and setIdAttributeNS. And finally a typo in
UserDataHandler.handle: "DOM applications must not raised

These are the only problems I've been able to find so far. Looking
forward to Rec!

Andrew Clover
Received on Thursday, 19 February 2004 07:53:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:12 UTC