Phil Mayers writes:
>The fundamental question is: are namespaces used incorrectly all over
>the place in Netconf?
JUNOS has some namespace issues, suffering from both pre-rfc
implementation problems and attempts to re-use the underlaying
Junoscript XML API code. PR 826463 is addressing these.
>I've looked at the PyEZ and ncclient code, and basically they seem to
>take the approach of just throwing away all namespace information. This
>seems icky to me, and make me wonder if Netconf is going to be another
>SOAP - so many implementation errors that "interop" ends up being a mess
>of special casing and workarounds.
Namespaces are a two-edged sword, and while they are great for
telling you _exactly_ what data you are seeing, this exactness
is often painful.
For example, each version of JUNOS uses a unique namespace, and
we publish specific data models (DTDs, XSDs, and soon YANG) for
each specific version. But a namespace like:
http://xml.juniper.net/junos/13.3I0/junos
means that an XPath expression (or the XSL script containing it)
would need that specific URI to match, which can be a maintenance
issue. For SLAX, I replace the version with "*" to make a namespace
that can be used across versions:
ns junos = "http://xml.juniper.net/junos/*/junos";
This is just an example and is disjoint from the issues in PR 826463,
where we mistakenly put elements from junos in netconf space and
vice versa.
Thanks,
Phil
_______________________________________________
juniper-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp