Eliot,
I think option 2 could be made palatable when used in combination with scoped keys. I am planning to rewrite the Phase 2 proposal for scoped keys to state that keys defined in a scope will be accessible from outside that scope, so a combination of a peer mapref for purposes of defining cross-deliverable keys, with a keyscope attribute, would define keys with a qualified name for use in the local scope, e.g.
<mapref scope="peer" keyscope="otherPublication" href=""/>
Assuming otherPublication.ditamap defines a key named 'someKey', it could be referenced via:
<xref keyref="otherPublication.someKey"/>
This wouldn't necessitate the presence of otherPublication as a peer map for all uses of that xref, because a different top-level map could provide an explicit definition for the qualified key name, e.g.
<topicref keys='otherPublication.someKey" href=""/>
Or define that scope as a local child of the root keyspace
<topicgroup keyscope="otherPublication"> <keydef keys="someKey" href=""/> </topicgroup>
The other thing I think might be desirable to make this work is some way to mark the peer mapref that brings in the key definitions as being for that purpose, something like processing-role="peer-keydefs", but I haven't really thought that through. I just worry about existing, customized processors that have special handling for peer maprefs being broken by new spec-mandated processing requirements.
Chris
In all our discussion of cross-deliverable linking we've talked about root maps and processing root maps to generate intermediate key definitions and I've proposed adding the ability to address root maps (key spaces) (proposal 13041).
However, something that I think may have gotten overlooked in this discussion is the implicit requirement that, for cross-deliverable linking to work, the author of a *referencing* map must know, by some means, what the potential peer root maps are.
Without this knowledge there is no way to know that a given map is or is not a root map: there is nothing inherent in maps generally that makes a given map be or not be a root map: a map is a root map because it was the input to a processor and for no other reason.
I don't think this knowledge requirement is a problem, it's simply a fact of how things work, a side effect of an implicit or explicit architectural choice to not distinguish root maps from other maps at the markup level, a choice that was and is probably the correct choice.
But it does mean that all solutions we consider can depend on *map authors* knowing which maps, out of all the maps they have knowledge of, are root maps and which are not.
This is important because a key definition, by itself, caries no information about what root map or maps it is a part of (and it may be part of many root maps).
The practical challenge is knowing, for a given peer key reference, which peer root map that peer key reference applies to.
In analyzing this more deeply I've come to the conclusion that there are only two possible ways to know this:
1. Define new addressing syntax that explicitly references the root map that defines the key space the referenced key is defined in (my proposal 13041)
2. Directly include as peer maprefs the root maps that define keys you want to point to from the referencing map.
Option (1) solves the problem directly by making the key-to-key-space binding explicit and direct. It avoids any requirement to make keys unique across all the peer maps referenced from a given referencing map.
Option (2) solves the problem indirectly by establishing the root definition context of each key, with the implication being that the referenced peer map from which a given key definition is descended is the root map the key applies to.
Option (2) requires that keys be globally unique across all the coordinated peer maps: because in the general case every root map will include every other root map as a peer, all keys defined in all the possible peer maps must be unique, otherwise, keys from one peer map could override keys from another peer map, in which case it would be impossible to point to overridden keys. In practice, for a set of root maps developed together (e.g., the document for a product or family of products or all the products an enterprise produces) the keys must be globally unique because you cannot predict what the peer-to-peer relationships might be in the future. This would require either an impossibly omniscient information management system or use of some form of UUID, both of which are pretty ugly options.
It would mean that you couldn't ever have common set of key definitions because each root map would need to have unique key names even for topics shared across root maps. Splitting or merging root maps wouldn't be a problem because all key names would remain unique after the split or merge, but you couldn't use naming conventions that include the root map name in the key names without having to rewrite key names in the case of split or merge.
I am really uncomfortable with requiring global key spaces across peer maps: I think it requires what is essentially an impossible management requirement in the general case. Thus, I continue to assert that proposal 13041 is essential for a practical solution to cross-deliverable addressing.
However, I do recognize that including peer root maps with a scope of "peer" is sufficient to indicate the ultimate owning root map of a given key definition. But note that this requires that the *root map* be the thing included in the referencing map, not just a separate key definition file that happens to be used from the root map.
Cheers,
E.
-- Eliot Kimber Senior Solutions Architect, RSI Content Solutions "Bringing Strategy, Content, and Technology Together" Main: 512.554.9368 www.rsicms.com www.rsuitecms.com Book: DITA For Practitioners, from XML Press, http://xmlpress.net/publications/dita/practitioners-1/
--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
Chris Nitchie Oberon Technologies, Inc. 2640 Wildwood Trail Saline, MI 48176 Main: 734.666.0400 Direct: 734.330.2978
|