[salud] An update of section 9

[[e-mail] (Dale R. Worley)]

[as an individual]

Here is a revision of section 9.  I think I've clarified the wording
in a lot of places, so there are a lot of small changes.  In addition,
I've used terminology taken from the updated BNF, which makes much
clearer which parts of URNs are being utilized at various points in
the algorithm.

The next section of the message is the updated section 9, and the last
section is a diff between the current text and the update, which makes
it a little clearer what has been changed and what hasn't.

----------------------------------------------------------------------
9.  Non-normative Algorithm for Handling Combinations of URNs

   The following text is a non-normative example of an algorithm for
   handling combinations of URNs that complies with the requirements in
   Section 8.  Thus, it demonstrates that requirements in section 7 are
   consistent and implementable.  (Of course, a device may use any other
   algorithm which complies with Section 8.)

9.1.   Algorithm Description

   For each <alert-category> (feature) known by the implementation,
   there is a "feature tree" of the known <alert-indication>s for that
   <alert-category>, with the sequence of <alert-ind-part>s in an
   <alert-indication> specifying the path in the tree from the root to
   the node representing the <alert-indication>.  For this
   description, we will name each tree and its root node by the
   <alert-category> name, and name each non-root node by the
   <alert-identifier>.  Each URN thus corresponds to one non-root node
   in one feature tree.

   For example, there is a tree
   named "source", whose root node is also named "source", and which has
   the children source:internal, source:external, source:friend, and
   source:family.  The URN urn:alert:source:external is placed at
   the node "source:external" in the "source" tree.  If the
   implementation understands urn:alert:source:[e-mail], there
   is a node source:[e-mail] that is a child of node "source".
   If the implementation understands
   urn:alert:source:external:[e-mail], there is a node
   source:external:[e-mail] that is a child of node
   source:external.
   (Of course, there
   are an infinite number of potential additional nodes in the tree for
   private values, but we don't have to represent those nodes explicitly
   unless the device has a signal representing the private value.)

   We assign similar locations to signals, but each signal has a
   position in *every* tree, describing the specific combination of
   meanings that it carries.  If a signal has a simple meaning, such
   as "external source", its place in the "source" tree is
   source:external, showing that it carries the "external source"
   meaning, but its place in every other feature tree is at the root
   node, meaning that it has no particular meaning for those features.

   A signal that has a complex meaning may have non-root positions in
   more than one feature tree.  For example, an "external, high
   priority" signal would be placed at source:external and priority:high
   in those trees, but be at the root in all other feature trees.

   In order to assure that the algorithm always selects at least one
   signal, we require that there is a "default" signal, whose position in
   every feature tree is at the root.  This default signal
   will never be excluded from the set of acceptable signals for
   any set of URNs, but will be the lowest-priority signal for any
   set of URNs.

   The algorithm proceeds by considering each URN in the received Alert-
   Info headers from left to right, while revising a set of signals.  The
   set of signals starts as the entire set of signals available to the
   device.  Each URN excludes some signals from the set, and *sorts* the
   signals that remain in the set according to how well they represent
   the URN.  (The details of these operations are described below.)  The
   first URN is the "major sort", and has the most influence on the
   position of a signal in the set.  The second URN is a "minor sort",
   in that it arranges the orders of the signals that are tied within
   the first sort, the third URN arranges the orders of the signals that
   are tied within the first two sorts, etc.

   At the end of the algorithm, a final, "most minor" sort is done,
   which orders the signals which remain tied under all the sorts
   driven by the URNs.  This final sort places the least specific
   signals (within their tied groups) *first*.  (If one signal's position in
   each feature tree is ancestral or the same as a second signal's
   position in that tree, the first signal is "less specific" than the
   second signal.  Other cases are left to the implementation to
   decide.)

   Once all the URNs are processed and the sorting of the signals that
   have not been excluded is done, the device
   selects the first signal in the set.

   Here is how a single sort step proceeds, examining a single URN to
   modify the set of signals (by excluding some signals and further
   sorting the signals that remain):

   o  The URN specifies a specific node in a specific feature tree.

   o  All signals in the set that are, within that feature tree,
      positioned at the URN's node, or at an ancestor node of the
      URN's node, are kept.  All other signals are removed from the
      set (because they have meanings that are incompatible with the
      URN's meaning).

   o  Each group of signals that are tied under the previous sorts are
      further sorted into groups based on how much of the URN's
      meaning they represent: those which are positioned at the node of the URN
      are tied for first position, those which are positioned at the parent node
      of the URN are tied for second position, etc., and those which
      are positioned at the root node of the feature tree are tied for last
      position.
----------------------------------------------------------------------
--- 07-section-9	2013-04-18 13:47:57.766306434 -0400
+++ 07-section-9-update-1	2013-04-18 14:13:40.669561605 -0400
@@ -1,78 +1,100 @@
 9.  Non-normative Algorithm for Handling Combinations of URNs
 
    The following text is a non-normative example of an algorithm for
    handling combinations of URNs that complies with the requirements in
    Section 8.  Thus, it demonstrates that requirements in section 7 are
    consistent and implementable.  (Of course, a device may use any other
    algorithm which complies with Section 8.)
 
 9.1.   Algorithm Description
 
-   For each category (feature), there is a tree of possible values.  For
-   this description, we will name each tree by the category name, and
-   name each node by the trailing portion of the URN.  Each URN thus
-   corresponds to a node in a category tree.  Thus, there is a tree
+   For each <alert-category> (feature) known by the implementation,
+   there is a "feature tree" of the known <alert-indication>s for that
+   <alert-category>, with the sequence of <alert-ind-part>s in an
+   <alert-indication> specifying the path in the tree from the root to
+   the node representing the <alert-indication>.  For this
+   description, we will name each tree and its root node by the
+   <alert-category> name, and name each non-root node by the
+   <alert-identifier>.  Each URN thus corresponds to one non-root node
+   in one feature tree.
+
+   For example, there is a tree
    named "source", whose root node is also named "source", and which has
    the children source:internal, source:external, source:friend, and
-   source:family.  For example, urn:alert:source:external is placed at
-   the node "source:external" in the "source" tree.  (Of course, there
+   source:family.  The URN urn:alert:source:external is placed at
+   the node "source:external" in the "source" tree.  If the
+   implementation understands urn:alert:source:[e-mail], there
+   is a node source:[e-mail] that is a child of node "source".
+   If the implementation understands
+   urn:alert:source:external:[e-mail], there is a node
+   source:external:[e-mail] that is a child of node
+   source:external.
+   (Of course, there
    are an infinite number of potential additional nodes in the tree for
    private values, but we don't have to represent those nodes explicitly
    unless the device has a signal representing the private value.)
 
-   We assign similar locations to signals, but each signal has a place
-   in *every* tree.  If a signal has a simple meaning, such as "external
-   source", its place in the "source" tree is source:external, but its
-   place in every other feature tree is at the root node, meaning that
-   it has no particular meaning for that feature.
+   We assign similar locations to signals, but each signal has a
+   position in *every* tree, describing the specific combination of
+   meanings that it carries.  If a signal has a simple meaning, such
+   as "external source", its place in the "source" tree is
+   source:external, showing that it carries the "external source"
+   meaning, but its place in every other feature tree is at the root
+   node, meaning that it has no particular meaning for those features.
 
    A signal that has a complex meaning may have non-root positions in
    more than one feature tree.  For example, an "external, high
    priority" signal would be placed at source:external and priority:high
    in those trees, but be at the root in all other feature trees.
 
    In order to assure that the algorithm always selects at least one
-   signal, we assume that there is a "default" signal, whose position in
-   every feature tree is at the root.  The default signal is set up so
-   that it will never be excluded from the set of acceptable signals for
-   an indication, but will usually be the least-desirable signal for any
-   indication.
+   signal, we require that there is a "default" signal, whose position in
+   every feature tree is at the root.  This default signal
+   will never be excluded from the set of acceptable signals for
+   any set of URNs, but will be the lowest-priority signal for any
+   set of URNs.
 
    The algorithm proceeds by considering each URN in the received Alert-
-   Info header from left to right, while revising a set of signals.  The
+   Info headers from left to right, while revising a set of signals.  The
    set of signals starts as the entire set of signals available to the
    device.  Each URN excludes some signals from the set, and *sorts* the
    signals that remain in the set according to how well they represent
    the URN.  (The details of these operations are described below.)  The
    first URN is the "major sort", and has the most influence on the
    position of a signal in the set.  The second URN is a "minor sort",
    in that it arranges the orders of the signals that are tied within
    the first sort, the third URN arranges the orders of the signals that
    are tied within the first two sorts, etc.
 
    At the end of the algorithm, a final, "most minor" sort is done,
-   which orders the signals which have been tied under all the sorts
+   which orders the signals which remain tied under all the sorts
    driven by the URNs.  This final sort places the least specific
-   signals (within their groups) *first*.  (If one signal's position in
-   each category tree is ancestral or the same as a second signal's
+   signals (within their tied groups) *first*.  (If one signal's position in
+   each feature tree is ancestral or the same as a second signal's
    position in that tree, the first signal is "less specific" than the
    second signal.  Other cases are left to the implementation to
    decide.)
 
-   Once all the URNs are processed and the sorting is done, the device
+   Once all the URNs are processed and the sorting of the signals that
+   have not been excluded is done, the device
    selects the first signal in the set.
 
    Here is how a single sort step proceeds, examining a single URN to
    modify the set of signals (by excluding some signals and further
    sorting the signals that remain):
 
-   o  The URN specifies a specific node in a specific category tree.
+   o  The URN specifies a specific node in a specific feature tree.
 
-   o  All signals in the set that are positioned at that node, or at an
-      ancestor node of the URN, are kept.  All other signals are removed
-      from the set.
-
-   o  Within any group of signals that are tied under the previous
-      sorts, place first those which are at the node of the URN, place
-      second those which are at the parent node of the URN, etc., and
-      place last those which are at the root node of the feature tree.
+   o  All signals in the set that are, within that feature tree,
+      positioned at the URN's node, or at an ancestor node of the
+      URN's node, are kept.  All other signals are removed from the
+      set (because they have meanings that are incompatible with the
+      URN's meaning).
+
+   o  Each group of signals that are tied under the previous sorts are
+      further sorted into groups based on how much of the URN's
+      meaning they represent: those which are positioned at the node of the URN
+      are tied for first position, those which are positioned at the parent node
+      of the URN are tied for second position, etc., and those which
+      are positioned at the root node of the feature tree are tied for last
+      position.
----------------------------------------------------------------------

Dale