[NETCONF-1019] Create NamespaceURN constant holder Created: 05/May/23  Updated: 06/May/23  Resolved: 06/May/23

Status: Resolved
Project: netconf
Component/s: netconf
Affects Version/s: None
Fix Version/s: 6.0.0

Type: Task Priority: Medium
Reporter: Robert Varga Assignee: Robert Varga
Resolution: Done Votes: 0
Labels: pt
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to NETCONF-1017 Centralize NETCONF capability URNs Resolved
relates to NETCONF-1018 NetconfNotification confuses its name... Resolved

 Description   

As explified in NETCONF-1018, constants get easily confused, especially when held together with similar constants with a different use – just as we do in XmlNetconfConstants.

NETCONF-1017 creates CapabilityURN as holder class for URNs used in the context of NETCONF Capabilities. Create NamespaceURN as holder class for URNs used in the context of XML namespaces.

This should make use of constants more steamlined and hopefully will help catching day-0 bugs during code review.

 Comments   
Comment by Robert Varga [ 05/May/23 ]

A quick examination shows that restconf-nb is using the namespace constants as well – which means we are reaping the benefits of NETCONF-892/NETCONF-944 and are actually finding commonalities.

NamespaceURN is leading the way, and it should be defined at protocol layer. Create a new component, protocols/netconf-common and a corresponding feature (odl-netconf-common), to host these definitions.

Going forward, as we disaggregate restconf-nb (which has no protocols/ or plugins/ presence), we are sure to find more concepts that as shared.

A note on naming: just as netconf.git reflects the fact that both NETCONF and RESTCONF come from IETF's NETCONF Working Group, so does 'netconf-common' – with "NETCONF Working Group" being implied here. At the end of the day we have expected this sort of outcome from the get to, it is just now that we start taking advantage of the commonalities.

Generated at Wed Feb 07 20:16:28 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.