OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Kimber's comments on proposal 13061: ux-window







From: Eliot Kimber <ekimber@rsicms.com>
To: Anthony Self <tself@hyperwrite.com>, Stan Doherty <stan@modularwriting.com>, Don R Day <donrday@contelligencegroup.com>, 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






[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]