Clarification needed wrt nested references from maps to maps to topics

I think the DITA TC still needs to make some decisions to
clarify in the DITA 1.2 spec certain issues on topic references.

Don asked that I send this to the list for 1.2 consideration.

Consider a case such as the following:

Bookmap

Part to map

Map

Topicref to topic1

Topicref to topic2

Topicref to topic3

It seems the above should result in:

Part (topic1)

Topicref (topic2)

Part (topic3)

What's still not clear is what happens to topicrefs or
specializations other than the top level topicrefs in the
referenced maps (topicref to topic2 in the example).  I
believe we need to clarify what happens to the 2nd and
deeper levels.

Here are some other questions that don't seem answered
by the latest spec:

1. If there is a topicref within a part in a bookmap that

references another bookmap that includes a chapter at

the top level, is the chapter changed into a topicref

or does the chapter remain a chapter because we only make

changes for specialized topicref elements?

2. If someone references a map from a part in a bookmap and

the map has a single top level topicref and several lower

level topicrefs nested within the top level topicref,

the top level topicref becomes a part.  What, if anything,

do the nested topicrefs become?  chapters?  Or do they

just remain topicrefs?  Can a high level map author override

the element type for just the top level element or is there

a way to override the type of nested elements as well?

3. Again regarding referencing a map, what do we do when the

referenced map content is out of context after it has been

referenced from a higher level map no matter what element

type changes we do. Our choices would seem to be

(i) put the burden on the map author and if they produce

something that doesn't make sense, produce an error message;

(ii) provide rules for how we'll implicitly change element

types based on the map coding and the context so that things

remain legal;

(iii) some combination of (i) and (ii) that would change

common cases and treat the rest as errors, or;

(iv) leave this up to the implementation.

paul