Indirection, Keyref, and "Logical Name Reference" Requirements

["W. Eliot Kimber" <ekimber@innodata-isogen.com>]

Before we get too deep into a discussion of keyref and my indirection 
proposal I want to make sure that we have clear definition of the use 
cases and requirements because I strongly suspect that there are both 
distinct requirements at work and a not necessarily crisp description of 
all the relevant use cases.

Here's what I think the primary use cases are that are addressed by some 
form of indirection or "dynamic" resolution:

1. Referencing an ultimate target by initial reference to an indirector 
whose own address is invariant (that is, protecting the initial 
reference from changes in the location of the ultimate target) where the 
form of initial address uses the same syntax and semantics as a direct 
reference to the ultimate target would use.

2. Referencing an ultimate target by reference to an invariant "logical 
name" that is resolved to a specific target or targets based on 
properties statically determined by the context of the reference, such 
as audience, national language, etc. Typical specific use cases here 
include:

   - "variables" where the variable name is invariant but the set of 
specific values used is determine based on properties set for the 
context in which the variable reference occurs, such as the national 
language or product identifier.

   - mentions of things that will vary based on things like the national 
language for which the product being documented is localized, a typical 
example being the descriptions of keys on a mobile phone keyboard. The 
logical key name is invariant but the specific key name and graphic will 
vary and can be statically stored in a separate data set or data base.

3. Referencing an ultimate target by reference to an invariant address 
that is resolved to different targets based on resolution-time 
parameters provided to the resolution processor. For example references 
to graphics where the specific graphic object is determined based on the 
target output format (HTML or PDF) and possibly other parameters 
(national language, etc.).

4. Referencing a reference topic "implicitly" simply by uttering a value 
of its metadata or content (e.g., title, short title, navtitle, etc.). 
The resolution is resolved either at processing time based on the actual 
content of the topics involved and not on some form of indirect address 
or database lookup.

Note the key differences between these use cases:

Case 1. is just about addressing and is completely static--there is no 
special resolution-time processing other than simply doing the re-direction.

Case 2. is resolved based on *static* properties determined by the 
content and metadata in the referencing context (e.g., by values set in 
a particular map). Returning the correct value requires that the 
resolution processor know where to look for a particular kind of value 
(that is, which database or which file) and which local properties to 
use to complete the lookup.

Case 3. is resolved based on *dynamic* properties specified at 
resolution time. Like case 2, the resolving system has to know where and 
how to look up a particular value (that is, which database or which file).

Case 4. is resolved based on processing time string matches and does not 
otherwise involve any sort separate database lookup.

I will try to expand on each of these use cases as time permits. In 
particular, I think that case 2 is important and I don't think it's 
really addressed by the current keyref proposal and it is certainly not 
addressed by my indirection proposal (because that's not the point of 
that proposal).

Cheers,

Eliot

-- 
W. Eliot Kimber
Professional Services
Innodata Isogen
8500 N. Mopac, Suite 402
Austin, TX 78759
(214) 954-5198

ekimber@innodata-isogen.com
www.innodata-isogen.com