[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] DITA 1.3 Proposal 13004: Scoped Keys
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]