Date: Sun Jun 18 10:34:38 2006
New Revision: 3447
- doc update
--- cpsskins/branches/paris-sprint-2006/locations/README.txt (original)
+++ cpsskins/branches/paris-sprint-2006/locations/README.txt Sun Jun 18
@@ -37,14 +37,15 @@
modifications must be monitored.
We have to maintain a mapping between locations and some data.
We assume that objects are locatable, i.e. by knowing the object we can know
@@ -56,13 +57,14 @@
Since we can't keep information about *all* the locations of a site we
must store some information about how locations and related to sublocations
Rules of inheritence
The "standard" behaviour for locations is to follow some sort of inheritence,
i.e. what is true of a given location is also true of its sublocations.
-This behaviour can be declined into rules:
+This behaviour can be declined into various rules:
- what is true of a location applies only to the location itself
@@ -72,9 +74,13 @@
+For each rule we have a location, a scope and some data. The scope determines
+the locations to which the rule applies.
In order to avoid conflicting statements we must assume that some rules
have precedence over others. To determine the order in which rules are to be
-applied in a given context we look for the nearest locations first.
+applied in a given location context we look for the nearest locations first.
Nearest location in a context
@@ -89,8 +95,8 @@
-the former is the nearest location, because the context is contained in it and
-because it is contained in all other locations.
+the former is the nearest location, because the location context is contained
+in it and because it is contained in all other locations.
We can sort locations as:
@@ -105,3 +111,10 @@
applied, and the context will contain no local information.
+Rules are applied starting from the one that has the nearest location until
+its scope covers the location context. The rule's data can then be associated
+to the location context.