RESTCONF participates in this game in that this API difference needs to be understood by RESTCONF, which gets the onus of dealing with XML->JSON translation without ever knowing the schema.

This is manifested at RemoteDeviceHandler exposing DOMRpcService – here input and output are required to be ContainerNodes. There are two implementations plugged into this – NetconfDeviceRpc and SchemalessNetconfDeviceRpc.

So now, we need a sal.connect.api.RemoteDeviceRpcs:

sealed interface RemoteDeviceRpcs {
  non-sealed interface Normalized extends RemoteDeviceRpcs, DOMRpcService {
    // Nothing else needed
  }

  non-sealed interface Raw extends RemoteDeviceRpcs, DocumentRpcService {
    // Nothing else needed
  }
}

plus, we need to define a new DOMService:

import org.w3c.Document;

interface DocumentRpcService extends DOMService {

  ListenableFuture<? extends Document> invokeRpc(@NonNull String namespaceURI, @NonNull String localName, @NonNull Document input);
} 

The result may perhaps be not a Document, but a more structured thing – that is left to be determined based on integration experience.

Also, https://git.opendaylight.org/gerrit/c/netconf/+/103168 is already flushing the incompatibility, hence we will need a solution quite soon.

A bit of prototyping shows that this may actually need to addressed starting with the interface exposed by SchemalessNetconfDevice – i.e. it probably should have its own RemoteDeviceHandler.

(brain dump)
Looking at this a bit more, we could start by making RemoteDeviceHandler disconnect from DOM concepts and also NetconfTopology.

https://git.opendaylight.org/gerrit/c/netconf/+/82678 introduced this:

    default void onDeviceReconnected(final PREF netconfSessionPreferences, final NetconfNode node);

Which is fueled by passing down the NetconfNode – this needs to be pushed back to netconf-topology, so it follows proper up/down/reconnect lifecycle (via onDeviceDisconnected()). This should be possible, AFAICT.

The next up unsolicited messages – for NETCONF this can only be a notification:

    void onNotification(DOMNotification domNotification); 

This should be a generic parameter of RemoteDeviceHandler – i.e. the format of unsolicited messages. It might be DOMNotification, assuming schemas, but at the end of the day this could as well be a message, which in turn comes to RemoteDeviceCommunicator specialization, which would naturally be a NetconfNotification!

The thing is: the schemaless case of using org.w3c.Document is already handled by raw NetconfMessage, which begs the question, what is the key driver behind the use case. And it really is for netconf-topology to have:

final RemoteDevice<NetconfSessionPreferences, NetconfMessage, NetconfDeviceCommunicator> device; 

and having a NetconfDeviceCommunicator working on top of that. The interaction with services then around back to NetconfDeviceSalFacade, which has onTopologyDeviceConnected() – which reflects back the services received on RemoveDeviceHandler callback. Note that onTopologyDeviceConnected() is again a leak of "topology" concept, but at this particular it should be called "onMountPointConnected". RemoteDeviceId is the key offender here: at the end of the day, this should be interface only YangInstanceIdentifier (and perhaps InetAddress, which is low-enough of a concet), as that is what we need to talk to DOMMountPointService – so topology-netconf should be filling out this part of RemoteDeviceId:

    private RemoteDeviceId(final String name) {
        this.name = requireNonNull(name);
        topologyPath = DEFAULT_TOPOLOGY_NODE.node(NodeIdentifierWithPredicates.of(Node.QNAME, NODE_ID_QNAME, name));
        key = new NodeKey(new NodeId(name));
        topologyBindingPath = DEFAULT_TOPOLOGY_IID.child(Node.class, key);
    }

There might be more, but really, sal-netconf-connector is the binding between netconf-api and mdsal-dom-api – it must not depend on topology model in any shape or manner.

Circling back for a minute on the grand scheme of things: sal-netconf-connect has multiple parts, which perhaps should split out to multiple components (but not now!). This is:

1. setting up the device for use with DOMService APIs, then
2. passing the lifecycle baton back to the user (i.e. netconf-topology) via RemoteDeviceHander.onDeviceConnected(), then
3. supporting that user in binding that device to DOMMountPointService

This means onDeviceConnected() does not break down all the services available in terms of individual DOMServices, but rather a generic handle (i.e. a sealed interface) with perhaps known specializations (as hinted by RemoteDeviceRpcs in above proposal), but really encapsulating everything but the session preferences. That sealed interface will be reflected back to us in step 3) which when we make sense of it.

Hence all of the possibilities in RemoteDeviceHandler.onDeviceConnected() need to be refactored a single method:

void onDeviceConnected(PREF netconfSessionPreferences, RemoteDeviceAccess access); 

I think we can safely specialize PREF to NetconfSessionPreferences, as there no other specializations. RemoteDeviceAccess is that sealed interface, which gets passed back to NetconfDeviceSalFacade and it will then make a decision what DOMServices to instantiate from that.

So let's break this down into multiple subtask to focus our effort.

This issue is flushing out a ton of technical debt w.r.t layering of information and control bits. At the end of the day sal-netconf-connector needs to be provide crisp components without being explicitly tied to netconf-topology.