The Conformance clause needs to be more specific
about the constraints that the RM places on
implementations, even if the information in the
Conformance clause is redundant.
Here are some ideas about how to be more specific about
what it means for software to be RM-conformant.
(1) RM conformant software accurately implements an
RM-conformant model.
(2) Since RM-conformant models can impose many strange
and wonderful constraints on their software
implementations, we can't say, comprehensively, how
RM-conformant software behaves.  A lot of the
behaviors will necessarily be model-defined.
(3) However, we can state certain minimum global
constraints on all implementations, in general
terms.  Here are some proposals:
(a) If a subject can implicitly exist, but can't be
a role player, according to the model in terms
of which a topic map is exported by an
implementation, that subject must not have any
proxies (s or whatever) in the topic map
documents exported by the implementation.
For example, if the "export model" (the model
to which the interchangeable topic map document
being output by an implementation declares
itself to conform) regards URIs as property
values but not as topics, no assertions about
the URIs that are those property values can be
exported, because it would be misleading to do
so.  The SLUO cannot be honored with respect to
subjects that exist but can't be role players.
This can be seen as an expression of the Prime
Directive of Information Interchange Standards:
"Do not use the standard syntax/protocol to say
anything that will not be understood in exactly
the intended way by every conforming
recipient."  Implementations that are "110%
conformant" to a model do not, in fact, conform
to that model, unless they filter out the extra
10% at export time.
On the other hand, this can also be seen as a
reason why it's critically important to allow
models to be extended, and to provide means
whereby topic maps can describe their own
models.  If a topic map is exported according
to a model that is 110% of some other model,
and it says exactly what model it really
conforms to, that's just fine.
(b) Whatever subjects *can* be role players must be
capable of playing any number of roles in any
number of assertions, except as the model may
prohibit.  In other words, RM-conforming
software cannot refuse to honor the playing of
any role by any subject, unless the playing of
such role by such subject would violate the
constraints imposed by the model.
(c) RM-conforming software must honor the merging
rules of the model.  Whatever subjects can be
role players in assertions must also be capable
of being recognized as identical to themselves,
whenever they have multiple proxies.  (This is
really more of a constraint on the models than
on their implementations.)
(d) RM-conforming software must not export
interchangeable topic map documents that both:
i. claim to conform to the standard, and
ii. don't conform to the constraints of the
model that such documents (implicitly or
explicitly) claim to conform to.
(e) There is *no* requirement that the
interchangeable topic map documents exported by
RM-conforming software be inherently
fully-merged, unless such a requirement is
imposed by the interchange syntax.  (Neither
XTM nor HyTM impose such a restriction, nor can
they.)
(f) Whatever requirements are imposed by the RM on
all models are, of course, also imposed on all
implementations of all models.  These include:
i. A-nodes, r-nodes, and t-nodes must be
capable of being role players.
ii. Either *all* c-nodes must be capable of
being role players, or *no* c-nodes must
be capable of being role players.
iii. Full merging requires that assertions
must always merge according to the
merging rules provided by the RM for
assertions.
iv. Within each assertion, the properties of
nodes must make it possible to traverse
(directly or indirectly):
* from each role player to the
a-node,
* from each role player to its respective
r-node,
* from each role player to every other
role player, and
* from the a-node to the t-node, if any.

The Conformance clause needs to be more specific
about the constraints that the RM places on
implementations, even if the information in the
Conformance clause is redundant.
Here are some ideas about how to be more specific about
what it means for software to be RM-conformant.
(1) RM conformant software accurately implements an
RM-conformant model.
(2) Since RM-conformant models can impose many strange
and wonderful constraints on their software
implementations, we can't say, comprehensively, how
RM-conformant software behaves.  A lot of the
behaviors will necessarily be model-defined.
(3) However, we can state certain minimum global
constraints on all implementations, in general
terms.  Here are some proposals:
(a) If a subject can implicitly exist, but can't be
a role player, according to the model in terms
of which a topic map is exported by an
implementation, that subject must not have any
proxies (s or whatever) in the topic map
documents exported by the implementation.
For example, if the "export model" (the model
to which the interchangeable topic map document
being output by an implementation declares
itself to conform) regards URIs as property
values but not as topics, no assertions about
the URIs that are those property values can be
exported, because it would be misleading to do
so.  The SLUO cannot be honored with respect to
subjects that exist but can't be role players.
This can be seen as an expression of the Prime
Directive of Information Interchange Standards:
"Do not use the standard syntax/protocol to say
anything that will not be understood in exactly
the intended way by every conforming
recipient."  Implementations that are "110%
conformant" to a model do not, in fact, conform
to that model, unless they filter out the extra
10% at export time.
On the other hand, this can also be seen as a
reason why it's critically important to allow
models to be extended, and to provide means
whereby topic maps can describe their own
models.  If a topic map is exported according
to a model that is 110% of some other model,
and it says exactly what model it really
conforms to, that's just fine.
(b) Whatever subjects *can* be role players must be
capable of playing any number of roles in any
number of assertions, except as the model may
prohibit.  In other words, RM-conforming
software cannot refuse to honor the playing of
any role by any subject, unless the playing of
such role by such subject would violate the
constraints imposed by the model.
(c) RM-conforming software must honor the merging
rules of the model.  Whatever subjects can be
role players in assertions must also be capable
of being recognized as identical to themselves,
whenever they have multiple proxies.  (This is
really more of a constraint on the models than
on their implementations.)
(d) RM-conforming software must not export
interchangeable topic map documents that both:
i. claim to conform to the standard, and
ii. don't conform to the constraints of the
model that such documents (implicitly or
explicitly) claim to conform to.
(e) There is *no* requirement that the
interchangeable topic map documents exported by
RM-conforming software be inherently
fully-merged, unless such a requirement is
imposed by the interchange syntax.  (Neither
XTM nor HyTM impose such a restriction, nor can
they.)
(f) Whatever requirements are imposed by the RM on
all models are, of course, also imposed on all
implementations of all models.  These include:
i. A-nodes, r-nodes, and t-nodes must be
capable of being role players.
ii. Either *all* c-nodes must be capable of
being role players, or *no* c-nodes must
be capable of being role players.
iii. Full merging requires that assertions
must always merge according to the
merging rules provided by the RM for
assertions.
iv. Within each assertion, the properties of
nodes must make it possible to traverse
(directly or indirectly):
* from each role player to the
a-node,
* from each role player to its respective
r-node,
* from each role player to every other
role player, and
* from the a-node to the t-node, if any.

Software conforms to the RM if it implements an RM-conformant model in
a way that conforms to that model, and, additionally, if its
implementation of syntactical representations of that model conform to
the specifications of those syntaxes.

The constraints placed on models were harder to work out, but the
summary seems to be that it must be possible to impose an
RM-consistent view on the models, which seems to me like a good way to
formulate this. It means the models can be specified according to many
different world-views and still be judged using the RM.
The constraints on seem to be as follows (I'm assuming the first of
the two interpretations given in the table above):
- proxies for subjects must either
- support being role players, (and if so,
- be capable of participating in any assertions not restricted by
the model (3b),
- have a well-defined equality rule (3c)
- not support being role players, in which case I can't see any
constraints on them. (Did I miss something?)
In addition come the constraints in 3f, which I must confess I don't
fully understand. They seem reasonable, but more explanation of them
would be welcome.

One thing worthy of note is that it seems to me that these constraints
are somewhat tautological if the mapping from the models to be tested
for conformance to the RM are left unspecified. In that case it seems
to me that for *any* model whatsoever it will be possible to create a
mapping that produces a conforming model.

As far as I can see there are also constraints on the syntactical
expressions of RM-conforming models; that is, constraints on the
specifications of the syntaxes of RM-conforming models.
This is, as far as I understand:
- subjects whose proxies cannot be role players are not allowed to
have syntactical proxies (3a).