[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Scoped Keys and Relationship Tables: I Think We Need to Say Something in the Spec
|
In updating the section of my book on relationship tables to reflect DITA 1.3/2.0, I realized that it’s not clear from the 1.3 spec, at least not that I’ve found, what the implications for key scopes are for relationship tables. Both the 1.3 and 2.0 (current draft) reltable topics say simply: Within a map tree, the effective relationship table is the union of all relationship tables in the map. This does not address the implications for key scopes when the retables being unioned include reltables within submaps that are in a key scope, either because the mapref is within (or specifies) a key scope or because the submap specifies
a key scope. I think the only right answer is that the effective result preserves the original resolved result with respect to the applicable keyscopes, but I don’t see anything in the spec language that requires that. I think this language needs to be expanded to say something like: ------- Within a map tree, the effective relationship table is the union of all relationship tables in in the map. For relationship tables included from maps that are in or that define a key scope, key references within those relationship tables
are resolved in the context of the applicable key scopes. ------- Conceptually, the set of effective related links is the set of links defined in all reltables included in any submaps as well as any reltable links defined in the root map, resolving keyrefs from reltables in the context of the key scopes
each reltable is in. That is, if the map grammar allowed <reltable> to occur anywhere <topicref> is allowed (which maybe it should now that I’m thinking about it), then a literal map resulting from resolving submaps would not need to “union” any relationship
tables, they could just go where they were originally and thus would still be within whatever key scopes they were authored in. That would allow normal scoped key resolution do the right thing for keyrefs within relationship tables. However, if the result of a map resolution operation is a map that could be valid to the current map content models, all the subordinate reltables would need to be moved into the root map element. In doing so, it would be necessary to rewrite
topicrefs and, potentially, add new keyscopes to ensure that the rewritten keyrefs can be resolved to the correct topics. For a deeper discussion, consider this system of maps: <?xml version="1.0" encoding="UTF-8"?> The root map has a reltable that relates topic-01 to topic “topic-02” from submap 1 and a different topic-02 from submap 2. The targets
of the key references in the root reltable are clear because the key scopes are defined in the same map that contains the reltable. That is, there can be no question that the key reference “sub01.topic-02” refers to topic-02.dita as used from submap-01.ditamap. Each submap also includes a relationship table. Both relationship tables relate their respective topics topic-02 and topic-03 together. To merge these three reltables together, the challenge is ensuring that effective scope qualifications in reltables from submaps are
preserved so that key references in the combined reltables continue to resolve to the original resources. If we model the result as a literal resolved map where the reltables from submaps contribute new rows to the reltable from the root map,
then in order to maintain the original key references, the result would need to add scope qualifications to the key references:
<map><title>Root Map</title> This is easy in this case because each submap was associated with a unique scope name. But scope names don’t need to be unique. For example, rather than specifying scope names on the maprefs, each submap might specify @keyscope on its own <map> element and both
maps might use the same scope name. In this case, the in-submap key references are still distinct because key references are always resolved within their scope unless overridden
by an ancestor (which they are not in this case). Thus, when merging in these two submaps, the processor would need to assign new, distinct, key scopes to each submap so that those scope
names could then be used in the reworked keyrefs from relationship table cells. There’s no programmatic challenge with that—the processor doing the map resolution has all the knowledge it needs to ensure the key scope
names are unique and since it’s generating a new result map it can do whatever it wants in terms of adding additional key scope declarations. Cheers, E. ___________________________________________ Eliot Kimber Sr Staff Content Engineer O: 512 554 9368 M: 512 554 9368 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]