[sc34wg3] comment on RM: constraints on implementations

[Steven R. Newcomb]

REF: parid0446

COM: 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 (<topic>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.



END


-- Steve

Steven R. Newcomb, Consultant
srn@coolheads.com

Coolheads Consulting
http://www.coolheads.com

voice: +1 972 359 8160
fax:   +1 972 359 0270

1527 Northaven Drive
Allen, Texas 75002-1648 USA