Re: L2-core-getElementsByTagNameNS02

----- Original Message -----
From: "David Brownell" <david-b@pacbell.net>
To: "Curt Arnold" <carnold@houston.rr.com>
Cc: <www-dom-ts@w3.org>
Sent: Wednesday, November 21, 2001 11:19 PM
Subject: Re: L2-core-getElementsByTagNameNS02


> > Does GNUJAXP implement the bahavior that you are expecting?
>
> Yes:  "In NO namespace" != "In ANY namespace".
>
>
> >  Could you post the overall test results from GNUJAXP.
>
> Referring to the DOM-TS tests from CVS as of a couple days ago,
> and just summarizing results with the current GNUJAXP release ...
> everything passes EXCEPT:
>
>   - Quite a number of the tests that try to verify behavior for
>     readonly nodes produce errors because instead of using
>     such nodes as found in the document, they try to create
>     new entity refs ... such refs are created with no children.
>
>     Seems to me a number of those tests would be better if
>     they verified that behavior using the entity ref nodes in the
>     document.  And those tests should likely not execute
>     when the parser isn't populating entity refs.  (Lots of tests
>     such as "unreadablenamenomodificationallowederr" fail,
>     about a dozen total, this is the main L1 failure mode. :)
>
>     (This is an area where IMO there are longstanding API
>     deficiencies in DOM.  First, you can't mark subtrees as
>     readonly.  Second, entities and entity refs, in their entirety.
>     I recall discussions late in DOM L1 to ensure it was legal
>     to never populate these nodes, yet these tests insist that they
>     must always be populated.)

Could you point out something in the specs that would support an entity
reference created with createEntityReference not being identical to an
entity reference that was created due to an entity reference in the source
document?

If that was allowable, then you should never trust the child contents of an
entity reference.

The tests that were expected to raise a NO_MODIFICATION_ERR. as submitted
from NIST , depended on entity references being preserved.  However, since
an implementation is free to expand entity references (for example, Xerces-C
cannot preserve entity references), these tests would be skipped and the
particular behavior not tested.  To test the same behavior for
implementations that expanded entity references (or for implementations
where this behavior is switchable), I created variants of the NIST supported
tests that created the equivalent entity reference and added an EE suffix.

So for implementations (or configurations) that support entity preservation,
the same behavior is tested with both entity references created from the
base document and entity references created using createEntityReference.
For implementations or configurations that expand entity references, only
the createEntityReference test is run.

Xerces-J 1.4.3 shows an interesting behavior, when entity reference
preservation is on, the createEntityReference tests pass.  However, the same
tests fail when entity references are expanded.  It seems inappropriate that
the document loading configuration should affect the behavior of subsequent
document manipulation.


>   - Some of the L2 importNode tests acted strange.  I need to
>     look at them some more.  For example, one seems
>     to expect that importing a no-namespace node will cause
>     the imported node to acquire a namespace.
>     (importNode{07,10,11,12} gave problems.)
>
>   - 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).
>
> In one parser mode, some more of the L2 tests failed,
> such as some "prefix" tests.  Haven't had a look at any
> of those to see what's up yet, could be a bug in tests or
> in the implementation.  For L1 it was mostly those "create
> another populated entity ref" tests that failed.
>
> - Dave
>
>
>
>

Received on Sunday, 25 November 2001 23:59:38 UTC