#1 L2-core-getElementsByTagNameNS02

[Curt Arnold]

David Brownell wrote in
http://lists.w3.org/Archives/Public/www-dom-
ts/2001Nov/0025.html

I was looking at this and I think either the test
needs to change
or the specification does. The relevant parts of the
test (in Java):

newList = doc.getElementsByTagNameNS
("*", "employee");
newElement = (Element)newList.item (3);

The problem is that only two elements have a
namespace URI,
and that "*" is supposed to match "all namespaces".
Those two
elements are:

- <employee> ... EMP0001, Margaret Martin
- <emp:employee> ... EMP0004, Jeny Oconnor

Now, either the spec should be changed so that "*"
means to
ignore any namespaces (and thereby match elements
that are
not in any namespace), or (preferably) the test
should change
so that it accesses item 1, not item 3.

- Dave

[Curt Arnold]

Logged In: YES
user_id=27193

Curt Arnold wrote http://lists.w3.org/Archives/Public/www-
dom-ts/2001Nov/0026.html

From the narrative of the test, the author clearly expected
getElementsByTagNameNS to return five elements. Xerces-J
1.4.3, Crimson 1.1.3 and a recently nightly build of
Mozilla (the only implementations have tested so far)
returned 5 elements interpreting the call to be equivalent
to the XPath expression descendent::*[local-name() =
$tagname] not decendent::*[namespace-uri() and local-name
() = $tagname]

There should be only one right answer to the result of the
query, either 5 or 2 elements. Changing the test so that
the assertion is nodelist.size >= 2 doesn't help anyone.
Since the test narrative clearly says it expects 5
elements, I added a corresponding assertion to the body of
the test. If the ultimate correct answer is 2, then the
test should be changed to require exactly 2 elements in
the node list.

I would agree that your interpretation of the
recommendation text is
reasonable and possibly what the WG was trying to say, but
if all (or almost
all) the implementations read it a different way, then I
would suggest an
errata to ratify the defacto behavior. Will need to get
more data points on
the implementations.

[Curt Arnold]

Logged In: YES
user_id=27193

David Brownell wrote in
http://lists.w3.org/Archives/Public/www-dom-
ts/2001Nov/0030.html

> If the
> ultimate correct answer is 2, then the test should be
changed to require
> exactly 2 elements in the node list.
>
> I would agree that your interpretation of the
recommendation text is
> reasonable and possibly what the WG was trying to say,
but if all (or almost
> all) the implementations read it a different way, then I
would suggest an
> errata to ratify the defacto behavior.

That's pretty much what I said ... either the spec has a
bug, or some implementations do. I think it's the
implementations, but the question does need to get
answered. Ratifying random bugs is a dangerous route.

How does the DOM WG get involved when such issues get
raised?

[Curt Arnold]

Logged In: YES
user_id=27193

David Brownell wrote in
http://lists.w3.org/Archives/Public/www-dom-
ts/2001Nov/0039.html

There's a similar problem with getElementsByTagNameNS04 ...
only three of the "address" element have a namespace: for
EMP001, EMP004, and EMP005. But the test is written to
expect that all of the "address" elements have namespaces.

- Dave

[Curt Arnold]

Logged In: YES
user_id=27193

David Brownell wrote in
http://lists.w3.org/Archives/Public/www-dom-
ts/2001Nov/0055.html:

> Does GNUJAXP implement the bahavior that you are
expecting?

Yes: "In NO namespace" != "In ANY namespace".

.... Other issues .....

Those L2 getElementsByTagNameNS tests, as mentioned,
where I think the tests are wrong (since they treat
the "no namespace" case like a "has a namespace" case).