From one of the docs, i have the below:
<?xml version="1.0" encoding="utf-8"?>
<rpc message-id="${TIMESTAMP}" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<running></running>
</source>
<filter>
<interface-configurations xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-ifmgr-cfg"/>
</filter>
</get-config>
</rpc>
This actually retrieves the interface configuration from the running config and works OK
Q1:How do i edit the same to retrieve interface statistics? What tags need to be used? How do i come to know?
Q2:I changed the line containing the namespace to some random line like 'http://a.b.c.d/check' and it failed. Why?
How do i edit the same to retrieve interface statistics? What tags need to be used? How do i come to know?
Your example uses <get-config> standard operation, which only retrieves configuration, not operational state. If you wish to retrieve the latter, you need to use <get/>, which retrieves both configuration and state data.
<?xml version="1.0" encoding="utf-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="${TIMESTAMP}">
<get>
<filter>
<interface-configurations xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-ifmgr-cfg"/>
</filter>
</get>
</rpc>
There is no <source> parameter for this one, since it always retrieves running config plus operational state. The easiest way to get familiar with NETCONF, would be to read its specification.
I changed the line containing the namespace to some random line like 'http://a.b.c.d/check' and it failed. Why?
If by "failed" you meant that you received an <rpc-error>, that would be non-standard behavior. You should have gotten an empty <data/> response, since there are no nodes that match your filter. The filter requires an exact match.
<?xml version="1.0" encoding="utf-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="163">
<data/>
</rpc-reply>
NETCONF datastores rely heavily on namespaces since that solves the most common naming problems. For example, if you have two modules and they contain top-level elements that are named "my-config", you won't have a problem, because they are uniquely identified by module namespaces: {uri:a}my-config and {uri:b}my-config.
In your example, you asked for {http://a.b.c.d/check}interface-configurations, which simply does not exist. It is irrelevant that the interface-configuration part matches (local name), because you requested a specific interface-configuration from a specific namespace.
Namespaces are (kind of) like house addresses. There may be numerous John Smiths in existence, but you can address a specific one by stating his full address. If you ask your local post to send a package to just the name "John Smith", without an address, the post would have no idea which one you meant.
Note: if you meant that you changed the urn:ietf:params:xml:ns:netconf:base:1.0 line, then the problem is the same. You attempted to execute some operation unknown to the server. This case would fail with an error response, however.