Subject: Kimber's comments on proposal 13061: ux-window
Looking at the proposal, I think that allowing ux-window only as a direct
child of <map> is problematic. I would very much like to be able to wrap a
container around my ux-window elements so that I can keep my maps neat at
the top level (meaning that the direct children of <map> are containers
that distinguish the different things in my map, e.g., the map metadata,
any keyrefs (within a topic group), the root topicref of the map
navigation, and any relationship tables).
Therefore, I would suggest that ux-window also be allowed as content of
<topicref> or, possibly better, within <topicmeta>—I think one can argue
that the window definitions are metadata for the map—they are certainly
resources. Alternatively, could define a new base element type to contain
the ux-window elements.
Also, looking at 13060, I think that @ux-windowref is underspecified. The
proposal says "Contains the name of the ux-window element which will be
used to display this topic when called from a Help API.”
What happens in the case where there are two ux-windowref elements with
the same name? For example, because you’ve included two sub maps that both
have ux-windowref elements with the same name? I don’t see any language in
either proposal that covers that case.
I would expect the normal first-in-map, top-down precedence rules to be in
effect but that needs to be stated explicitly.
I’m also thinking that there is probably a requirement to have different
ux-window definitions in different branches—the existence of
branch-specific filtering and key scopes probably demands the ability to
have branch-specific window definitions. That again argues for allowing or
requiring ux-window in <topicref> or <topicmeta> so that it can be
associated with a specific branch.
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"