Re: [dita] Key scopes and topicsetref

[Eliot Kimber <ekimber@contrext.com>]

I think I see what Chris is getting at: only through the use of keys can
topicsetref be made sensible.

But I think there's still an open question of what the key scope
relationship is between topicsetrefs and topicsets.

After thinking about it more I think the right answer might be to think of
topicsetref as a topicgroup that effectively contains the referenced
topicset rather than a use-by-reference that is replaced by the topicset.
That resolves the question of the key scope implications and makes it
clear that each topicsetref establishes a separately-addressable use of
the topicset.

In thinking about it now I see that topicsetref does address a use case
that simple peer-map-references do not, namely the "embedding" of subparts
of another deliverable within a referencing deliverable. Whether that
embedding is static or dynamic is not really important: what's important
is that the processing (and thus addressing) context of the topicset is
separate from its eventual inclusion in or reference from some other
deliverable. (One implication is that, from the context of the embedded
topicset I'll be able to navigate to other parts of the larger deliverable
the topicset is part of because the delivered topicset retains its
participation in its containing deliverable).

I'm still not sure this is a use case many people have but it does seem to
be a real use case that is materially different from basic
cross-deliverable linking.

My analysis: 

For topicsetrefs that use direct URI references to topicset elements there
is not enough information to know what the root map context of the
topicset is and therefore no way to reliably address topics within the
topicset (for all the reasons that direct URI references to topics from
other topics are not reliable: they don't tell you anything about the use
context of the referenced topic or, in this case, the referenced topicset).

If you use key references then the ambiguity is resolved because you are
forced to either include the topicset-including map as a submap of the
referencing map or establish the topicset-containing map as a peer map
(otherwise the key would be unresolvable).

For example, if I have Map B containing a topicset I want to reuse:

Map-B.ditamap:

<map>
 <topicset keys="topicset-01" id="dontcare">
   <topicref keys="topic-02" href="topic-02.ditamap"/>
 </topicset>
</map>

Then from Map A I have two choices: (1) use map B as a submap or (2) use
map B as a peer map:

1. Use Map B as a submap:

Map-A.ditamap:

<map><title>Map A</title>
 <mapref processing-role="resource-only"
    href="Map-B.ditamap"
 />
 <topicsetref keyref="topicset-01"/>

</map>

Map B is clearly a submap of Map A and the topicset reference is
unambiguous. Likewise, any key references to topics within the topicset
are unambiguous (because Map B is included in Map A and normal key space
construction and key resolution rules apply).

2. Use Map B as a peer map:

Map-A.ditamap:

<map><title>Map A</title>
  <mapref scope="peer" keyscope="map-b"
   href="Map-B.ditamap"
  />
  <topicsetref keyref="map-b.topicset-01"/>
</map>


Again the topicsetref is unambiguous and key references to keys in the
scope "map-b" are resolved normally.

It becomes a processor task as to how to actually implement delivery of
the topicsetref but the relationship of the topicset to the topicsetref is
clear and key-based addresses to topics in the topicset are clear.

There's a still a problem when the same topicset is used more than once:

Map-A.ditamap:

<map><title>Map A</title>
  <mapref scope="peer" keyscope="map-b"
   href="Map-B.ditamap"
  />
  <topicsetref keyref="map-b.topicset-01"/>
  ...
  <topicsetref keyref="map-b.topicset-01"/>

</map>

There's no way to address topics in the topicset in the context of one or
the other of these references.


That is, if I have the key reference "map-b.topic-02" it is a reference to
the topic in Map B but without regard to any use context from Map A. I'll
get to the topic but the navigation context from Map A is undefined.

Since the point of topicsetref is to merge navigation it seems likely that
being able to establish use context in the referencing map is important.

If you put keyscopes on the references you can then distinguish the uses
of the topicset:

<map><title>Map A</title>
  <mapref scope="peer" keyscope="map-b"
   href="Map-B.ditamap"
  />
  <topicsetref keyscope="use-01" keyref="map-b.topicset-01"/>
  ...
  <topicsetref keyscope="use-02" keyref="map-b.topicset-01"/>

</map>

Now I can refer to keys in the scopes "use-01.???" and "use-02.???" and
make the Map A navigation context clear.

The question is still what is the key scope bound to the topicsetref and
what is its relationship to the topicset's key scope?

Thinking about it this way it now makes sense that the topicsetref's scope
becomes a *parent* scope for the topicset's scope, otherwise the uses
wouldn't be distinct (because they would collapse into a single scope with
multiple names).

That is, I should be able to refer to the key "use-01.map-b.topic-02" and
get to topic 2 from Map B as used by the second topicsetref. If the scope
"use-01" was just an alias for "map-b" then the use would not be
distinguished.

That argues against my earlier assertion that topicsetref should be
treated the same as peer map references.

One way to say this would be to say that topicsetref, rather than being a
direct use-by-reference of the topicset, functions as a topicgroup that
effectively contains or embeds the referenced topicset. That would make
the key scope relationship clear(er) and avoid potential implementation
mistakes like simply throwing away the topicsetref.

Cheers,

E.

----
Eliot Kimber, Owner
Contrext, LLC
http://contrext.com




On 4/13/16, 8:09 PM, "Chris Nitchie" <dita@lists.oasis-open.org on behalf
of chris.nitchie@oberontech.com> wrote:

>My assumption is that any topicsetref resolution should occur *after*
>keyref resolution, and the topicsetref functions as a reference to the
>topicset as contextualized at its location. If that's the case, then
>whether either or both elements specify @keyscope doesn't matter, because
>the topicsetref's resolution occurs after all keyrefs have been resolved
>at both locations.
>
>Chris
>
>
>
>
>On 4/13/16, 9:08 PM, "dita@lists.oasis-open.org on behalf of Eliot
>Kimber" <dita@lists.oasis-open.org on behalf of ekimber@contrext.com>
>wrote:
>
>>In the case of topicsetref and topicset, the 1.3 did not add any language
>>to define what the behavior should be when either or both of the
>>topicsetref and topicset specify a value for @keyscope.
>>
>>There are four possible cases:
>>
>>1. No key scopes. This is the 1.2 case and nothing is changed
>>2. Key scope on topicsetref but not on topicset
>>3. Key scope on topicset but not on topicsetref
>>4. Key scope on both topicsetref and topicset
>>
>>In cases (2) and (3) I think the correct behavior can only be that there
>>is one effective scope reflecting the scope name specified. While
>>topicsetref is defined as a use-by-reference of the topicset I don't
>>think
>>just throwing away a keyscope specified on it would ever be
>>appropriate--it's not a literal replacement but an application-managed
>>relationship between the navigation point in the referencing map and the
>>navigation structure defined by the topicset and that definitely argues
>>for maintaining the keyscope.
>>
>>In case (4) there are four possible behaviors:
>>
>>1. The two scope names are merged as for map-to-map references, resulting
>>in one key scope with two names.
>>2. The topicsetref's scope becomes the parent scope of the topicset's key
>>scope
>>3. The topicsetref's key scope is ignored
>>4. The topicset's key scope is ignored
>>
>>Option (1) is consistent with the explicit rules for map-to-map
>>references
>>and is my preference since it has the least surprise.
>>
>>Option (2) is logical but surprising and seems inconsistent with the
>>semantic of topicsetref as a use-by-reference.
>>
>>Options (3) and (4) are conref-type behaviors and in a real conref would
>>be controllable via the -use-conref-target keyword in the attribute
>>value.
>>That option is not available here so I think we can discard these
>>options,
>>especially since the writeup of topicsetref explicitly says it's not a
>>content reference.
>>
>>I don't recall ever discussing the implications of key scopes for
>>topicsetref. Did we?
>>
>>Based on my informal survey on DITA Users it doesn't appear that anyone
>>much uses topicsetref.
>>
>>But probably good for us to decide what the right answer is or explicitly
>>defer a decision to DITA 2.0.
>>
>>
>>
>>----
>>Eliot Kimber, Owner
>>Contrext, LLC
>>http://contrext.com
>>
>>
>>
>>
>>---------------------------------------------------------------------
>>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
>>