Re: should guidelines say something about NOT using IMPLIED?

["C. M. Heard" <heard@pobox.com>]

On Fri, 7 Feb 2003, Andy Bierman wrote:
>At 12:47 PM 2/7/2003 -0800, C. M. Heard wrote:
>>On Thu, 6 Feb 2003, Andy Bierman wrote:
>>> The issue with IMPLIED is that it can only be applied to the
>>> last component in an INDEX.  This limits future extensions.
>>> It prevents the creation of any associated table that would 
>>> extend the indexing scheme.  In practice, MIBs have defined
>>> such an extension by removing the IMPLIED keyword in the
>>> associated table.  This means an implementation cannot
>>> reuse the code from the 'primary' table because the sort
>>> order is different, and therefore data structures meant
>>> to be extended are actually replicated.
>>> 
>>> In a hierarchical data model (such as SMI-DS) the IMPLIED
>>> mechanism would severely limit the reusability and nesting
>>> flexibility of the data structures that used it.
>>
>>Thank you, Andy, for this excellent explanation.  I believe
>>that I understand the issue now.  Now the question is what
>>we want to say about it.
>
>We can say that it is not recommended because it has
>high implementation costs and low user benefit.  As Randy
>pointed out, it only provides alphabetical sort order for
>US-ASCII strings.

OK, the proposed text is shown below with '+' in the left-hand
margin. The target section is 4.6.3, "Conceptual Table Definitions".

   - For conceptual rows:

     - If the row is an extension of a row in some other table, then an
       AUGMENTS clause MUST be used if the relationship is one-to-one,
       and an INDEX clause MUST be used if the relationship is sparse.
       In the latter case the INDEX clause SHOULD be identical to that
       of the original table.

     - If the row is an element of an expansion table -- that is, if
       multiple row instances correspond to a single row instance in
       some other table -- then an INDEX clause MUST be used, and the
       first-mentioned elements SHOULD be the indices of that other
       table, listed in the same order.

     - If objects external to the row are present in the INDEX clause,
       then the conceptual row's DESCRIPTION clause MUST specify how
       those objects are used in identifying instances of its columnar
       objects, and in particular MUST specify for which values of those
       index objects the conceptual row may exist.

+    - Use of the IMPLIED keyword is NOT RECOMMENDED for any index
+      object that may appear in the INDEX clause of an expansion table.
+      Since this keyword may be associated only with the last object in
+      an INDEX clause, it cannot be associated with the same index
+      object in a primary table and an expansion table.  This will
+      cause the sort order to be different in the primary table and any
+      expansion tables.  As a consequence, an implementation will be
+      unable to reuse indexing code from the primary table in expansion
+      tables, and data structures meant to be extended might actually
+      have to be replicated.  Designers who are nonetheless tempted to
+      use IMPLIED because it results in a "natural" sort order for text
+      string index objects are urged to remember that this is at best
+      true only for US-ASCII strings and isn't true at all for general
+      UTF-8 strings.

Please let me know what you think.

//cmh