Kimber's comments on proposal 13061: ux-window

From: Eliot Kimber
          <>

        To: Anthony Self
          <>, Stan Doherty
          <>, Don R Day
          <>, Robert D
          Anderson/Rochester/IBM@IBMUS, 

        Date: 12/09/2013 13:41

        Subject: 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.

          

          Cheers,

          

          E.

          

          -- 

          Eliot Kimber

          Senior Solutions Architect

          "Bringing Strategy, Content, and Technology Together"

          Main: 512.554.9368

        www.reallysi.com

        www.rsuitecms.com