parid0433 | Sat, 22 Feb 2003 21:00:12
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.
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.