|
parid0433
| Sat, 22 Feb 2003 21:00:12
borrowed
included
See also parid0405">parid0405, parid0920">parid0920.
REF: parid0920">parid0920
TXT: borrowed
FIX: included
COM: See also parid0405">parid0405, parid0433.
REF: parid0406
TXT: The names of borrowed properties, assertion types and role types are
not affected by being borrowed; each remains as defined in the definition
of its TM Application of origin.
FIX: (delete?)
COM: Seems to imply that the definitions are *not* included as their
entirely (semantics and all). Also, is there a rule for resolving name
clashes? Does there need to be?
parid0433
| Sun, 02 Mar 2003 15:39:19
For each node, and for each TM Application that governs it, all of
the property values governed by that TM Application, including
properties defined in "borrowed" TM Applications, must be examined for
consistency with each other, as such consistency is defined by the
governing TM Application (see parid0363 5.2.6). If there are any
inconsistencies among the values of its SIDPs, they must be reported as
Reportable Topic Map Processing Errors.
(strike)
isn't consistency part of being defined and as such, should be checked when checking the definition? Perhaps not, but then we need a catch all, observes all the other constraints placed on the nodes or their values. |