YANG models are giving us a relatively-usable model of datastores, each defined as an identity. As YANG cannot define an abstract identity, some of these are not valid as datastore identifiers, but otherwise the generated classes should be okay.

Unfortunately this extensibility also means we can no longer maintain common.api.LogicalDatastoreType as a common enumeration shared by Binding and DOM.

In DOM world, a datastore is identified by its identity – hence it is a QName wrapped in a dom.api-specific final class. Note this class:

• must be a value object, i.e. no externally-visible constructors
• must be a WritableObject
• must validate the QName against well-known abstract identities
• must maintain a cache and/or an Interner

In Binding world, we can use generated classes directly and spell out that certain classes are invalid. binding.api implementations should consider enforcing this, although such checks should not be on critical paths.

Migration of LogicalDatastoreType.OPERATIONAL is straightforward, as it means operational store in both worlds. Slight twist in this regard is that there may be users who use this datastore as <intended> – which is not an immediate problem, but applications need to be advised to consider whether they want to work in <intended> as well – once we have that datastore supported.

Migration of LogicalDatastoreType.CONFIGURATION is less straightforward. In local (MD-SAL) context, this datastore corresponds to a fusion of the old 'config=true' datastores. The datastore itself represents <running>. MD-SAL does not support an explicit <candidate> store simply because of its transactional nature: each transaction is an isolated candidate store. Furthermore interaction between <running> and <startup> is left an implementation/use case detail – CDS persists at each committed transaction, IMDS never persists.

Therefore CONFIGURATION really means <running>, with the above restrictions. We will not define handling for <startup> and <candidate> – these will remain undefined in core APIs and will cause run-time failures if they are attempted to be used in contexts which do not support them.