3790 2006-10-04 04:18:26 +0000 spurious space in copynamespace-3.txt ... copynamespace-6.txt 2006-11-23 05:44:40 +0000 1 1 1 Unclassified XML Query Test Suite XML Query Test Suite unspecified PC Linux CLOSED FIXED P2 normal --- 1 per andrew.eisenberg carmelo public-qt-comments oldest_to_newest 12264 0 per 2006-10-04 04:18:26 +0000 The expected output files copynamespace-3.txt, copynamespace-4.txt, copynamespace-5.txt, and copynamespace-6.txt (for tests copynamespace-3, copynamespace-4, copynamespace-5, and copynamespace-6) contain a spurious spacr before and/or after the actual expected output. The compare mode is "Text" for these files, so they should not have any extra spaces. 12276 1 carmelo 2006-10-04 14:20:43 +0000 Per: Thanks for the comment. I removed the spurious characters from the tests results. Thanks, Carmelo 12911 2 tim 2006-11-10 16:03:24 +0000 Could you please explain why this space is spurious. For example, in copynamespaces-4 (below) the in-scope-prefixes($new//child::*) should return a sequence of three strings ("xml", "foo", ""). Either: 1. I'm wrong and the result of in-scope-prefixes should only be ("xml", "foo"). 2. I'm right but the space should be dropped for some reason (why?) - if so, the test doesn't discriminate between the results ("xml", "foo") and ("xml", "foo", ""). declare namespace foo = "http://example.org"; declare copy-namespaces preserve,inherit; (: insert-start :) declare variable $input-context1 external; (: insert-end :) let $existingElement := <existingElement xmlns="www.existingnamespace.com">{"Exi sting Content"}</existingElement> let $new := <foo:newElement xmlns = "www.mynamespace.com">{$existingElement}</fo o:newElement> for $var in (in-scope-prefixes($new//child::*)) order by $var ascending return $var 12912 3 per 2006-11-10 17:22:25 +0000 I think you're right, but it's been over a month and I don't remember clearly. I do remember looking at various testcase, thinking some should start with a space and some should not. If one wanted to test just in-scope-namespaces without at the same time testing serialization one could replace $var by (say) concat("[",$var,"]"). Of course one does want to test serialization, but perhaps those should be separate tests. 12927 4 per 2006-11-15 07:41:01 +0000 I took a look at these testcases, as well as a 3 other copynamespace-X that are (I believe) incorrectly failing. I believe the result for the following should include the empty prefix, so they should start with a space: copynamespace-3 - should return " xml" copynamespace-4 - should be " foo xml" copynamespace-5 - should be " foo xml" copynamespace-6 - should be " foo xml" In copynamespace-9 I believe 'newNamespace' should be inherited, so should be in the result. I.e.: copynamespace-9 - should be "newNamespace xml" For copynamespace-16, I believe when $element2 is copied into the <element3>constructor, the newly copied nodes *including the copied element1 node* inherit the namespace3 binding. So, according to my reading of the specification: copynamespace-16 - should be "namespace3 xml" I believe the same argument applies here: copynamespace-20 - should be "namespace3 xml" Hopefully, some experts can confirm or disconfirm my readings. 12930 5 per 2006-11-16 08:09:28 +0000 Constr-cont-nsmode-2 seems similar to opynamespace-9,c opynamespace-16, and copynamespace-20: It should have the inherited namespace: Constr-cont-nsmode-2 - should return "<z xmlns:inherit="inherit"/>" 12940 6 mike 2006-11-17 15:50:15 +0000 I concur with comment #4 that copynamespace-3 - should return " xml" copynamespace-4 - should be " foo xml" copynamespace-5 - should be " foo xml" copynamespace-6 - should be " foo xml" I agree with Per about the results of copynamespace-9, 16, and 20: in each case the result advocated by Per is the same as the result in CVS, so I'm not sure where the issue lies. 12944 7 per 2006-11-17 21:42:21 +0000 (In reply to comment #6) > I agree with Per about the results of copynamespace-9, 16, and 20: in each case > the result advocated by Per is the same as the result in CVS, so I'm not sure > where the issue lies. I think I somehow confused the expected and actual outputs. My apologies. Anyway, they're now the same. :-) 12977 8 andrew.eisenberg 2006-11-21 13:06:29 +0000 I've made the changes requested in comment #4. Please close this bug report if you agree with this resolution. 13011 9 per 2006-11-23 05:44:40 +0000 (In reply to comment #8) > I've made the changes requested in comment #4. > Please close this bug report if you agree with this resolution. Thanks!