- From: Arnold, Curt <Curt.Arnold@hyprotech.com>
- Date: Wed, 24 Apr 2002 13:36:57 -0600
- To: "'Mary Brady'" <mbrady@nist.gov>
- Cc: "'www-dom-ts@w3.org'" <www-dom-ts@w3.org>
[ca] I'm pretty sure that attrcreatetextnode3 does what the author of attrcreatetextnode was wanting to do but didn't quite accomplish. [mb] I disagree -- it was simply a mistake in invoking the entity. These tests were originally authored here at NIST, so I'm privy to what the author intended. This one was written early on and has simply been translated into java and then DOM TSML with the error. The intent of the test was to set it to "Y&ent1;" and it was simply an error. [ca] Maybe it is the mail lag, but you say that you disagree and then say exactly what I thought I was saying. Maybe it is the extra level of entity processing involved with DOMTSML, for me to get "Y&ent1;" in the code, the text of the DOMTSML has to read "Y&ent1;". The even numbered tests (2) and (4) do the same test but using setNodeValue() instead of setValue() since there was no other test that checked calling setNodeValue() for an attribute and reusing the existing test was the most expedient way of covering that function since setNodeValue and setValue are equivalent. With the two corrected tests, the value of the two flawed tests is minimal. They don't particularly hurt, but they don't help either. I was taking it as a general principle that we don't make substantive changes to a test after release so that the URL to a released test always means the same thing. However, since we haven't really established any convention for addressing tests, the disruption of making this particular change in place in inconsequential. So, I assume that your preference would be to delete attrcreatetextnode3 and 4 and to modify attrcreatetextnode and attrcreatetextnode2 so they do the same thing that 3 and 4 do now. If not, what would you suggest?
Received on Wednesday, 24 April 2002 15:35:22 UTC