Re: [dita] DITA 1.3 Proposal 13004: Scoped Keys

[Eliot Kimber <ekimber@reallysi.com>]

On 1/23/12 1:53 PM, "Nitchie, Chris" <cnitchie@ptc.com> wrote:

> These are all good comments. Some thoughts.
> 
> 1. There's no requirement that I'm aware of for addressing a key scope.
> However, note that the amount of information required to correctly
> address a key scope is not just the map URI and the scope name, because
> that doesn't specify the ancestor scopes. It's also not sufficient to
> provide the root map URI and the scope URI and name, since a sub-map may
> appear at multiple locations in a map structure, and in such cases you
> can't know the interceding scopes between the root and the scope in
> question. In order to properly address a scope, you'd need the full
> ancestry of the scope as identified by map URI and scope name (or
> topicref ID). So even if scope addressing is desirable, I'm not sure
> there's a feasible path starting from the provisions of this proposal.

I see your point--if the same map is included multiple times and defines any
key scopes, then you have multiple key scopes that happen to have the same
name and same map/topicref ID location but, because of inheritance, could
have different effective key binding sets.

Hmmm.

So yes, either you have to specify the path down the map tree or the
equivalent. That's of course doable, but I'm not sure it would be useful.

I think we actually have a more general problem of addressing use
contexts--that is, there's no good way to say "I'm addressing this topic in
this specific use context and not in some other user context." @copy-to
doesn't solve the problem in case of using the same map multiple times for
the same reasons Chris outlines.

So if were to try to solve this problem for key scopes the same solution
would apply to references to use contexts in general. I'm not suggesting we
try to solve it but just observing that it's a more general problem than key
scope addressing.

[In HyTime we had the notion of a "location ladder" that let you chain
addresss together to do exactly this. It was the only way to solve the
problem generally. The lowest rung of the ladder addressed the ultimate
target and then it addressed its "location source", which established the
context for resolving the direct address to the ultimate target, and so on
until you got to some invariant thing, which really meant "the processing
parameter set and starting conditions from which the data being addressed is
produced" (the root map and DITAVALs in our context). Not suggesting we
adopt that, just pointing out that the problem is both understood and has at
least one general-purpose solution.]

Cheers,

E.


-- 
Eliot Kimber
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"
Main: 512.554.9368
www.reallysi.com
www.rsuitecms.com