rvj wrote:

> BTW  I didnt really understand your comment :
> 
> "If you want to modify nodes (remove some children). Somebody has to  do
> that job - either DOM code or XSLT."

Try to picture XML tree and see yourself:

<a>
   <b>
   <c>
</a>

Here, //b/ancesor-or-self::* selection path gives you nodes <a> and <b>. 
   They are real nodes in the document, so <a> has two children - <b> 
and <c>. If you need the result to be
<a>
   <b/>
</a>

somebody has to remove node <c> from <a>. No magic here, it's tree, not 
flat list, if you select node <a>, then .xml property would give you 
full subtree of <a>.

> Its just that the nodeset generated for ancestors is really wierd   !!!!!!!!

I don't see what do you mean saying "weird". You just get original nodes 
in the document.

> DOM & XSLT are simply workarounds for the nodeset  generated when using
> ancestor.

Hehe, it's a funny way to name XML modification/transformation facilities.

> PS Can anyone confirm that the format of the ancestor nodeset listed in the
> previous post is normal or has it been been superceded by a later version of
> MSXML?
ancestor axis itself is of course normal. What is weird is the following 
code:

for (i=0;i<nodes.length;i++ )
{
   Response.write(nodes.nextNode().xml)
}

It's too naive as it presumes nodes in the nodelist can't be overlapping 
as in ancesor::* case - each one node contains immediately preceding one 
as a child and others as descendants. And the first one - root element 
contains all nodes in the tree (except document prolog).

-- 
Oleg Tkachenko [XML MVP]
http://blog.tkachenko.com