20.2. An aside: how does this work?
Consider for a moment an Admin role who adds a ModelManifest to the Repository for the perspectives.domains namespace. In his own PDR installation, the modified Repository instance, the new Manifests role instance and contexts and roles describing the new ModelManifest will be stored in his own local repositories. But because of the public roles, versions of these resources should be published as well. Let’s look in detail to some of these resources:
-
the new Manifests role is within scope of Repository$Visitor and thus will be published to
cw_servers_and_repositories -
however, its filler, the external role of ModelManifest, is within scope of ModelManifest$Visitor and should be published to
cw_perspectives_domains!
Consequently, the url of the Manifests role will be like this: https://perspectives.domains/cw_servers_and_repositories/<guid1>. But the url of the filler, the external role of ModelManifest, will be like this: https://perspectives.domains/cw_perspectives_domains/<guid1>. It appears that, on publishing, the PDR should look up the public url for each context type. If a context has a public role, the PDR should use it; otherwise the PDR just uses the public url of the publishing role. So, because the filler is a role of ModelManifest, the PDR uses its public URL to construct a pub: identifier.
Should it actually publish the external role itself (to the cw_perspectives_domains database)? It can only do so if the end user (or rather the Admin roles he plays) has the credentials that allow him to do so. To make that explicit: a Repository$Admin creating a new ModelManifest should have write access to
-
the
cw_servers_and_repositoriesdatabase for the CouchdbServer; -
the
cw_perspectives_domainsdatabase, or, in general, the database that holds the ModelManifest instances for the namespace described by the Repository.
We can actually arrange that in model://perspectives.domains#CouchdbManagement, and we should and have done so. So, under these circumstances: yes, the PDR should publish not only the new Manifests role instance, but also all role- and the context instances describing the new ModelManifest.
We consider this to be a model pattern. A user role with the perspectives to create a new context, where both the embedded context role and the new context have a public perspective, should have write access rights to both databases.
Now what if a user role has the perspective to create a new embedded context role that is filled with an existing public role? That is, its filler has the pub: scheme? In this case, the user role does not necessarily have the perspective to create such public roles (i.e. someone else made that role instance). However, his own version of that embedded context role will also be filled with an identifier in the pub: scheme. And on publishing, we just leave such references intact. All is well!