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
www.innodata-isogen.com
