Hi Aaron, Thanks for the explanation of "owns". Sounds like we agree on child of. Perhaps we should add the inverse relation to the atk/at-spi.
What will the IA2 mapping be? cheers, David Aaron Leventhal wrote: > ARIA owns is for things where there are children, but they are not > contained by the parent. > This is necessary to separate 2 types of parent concept: > 1. Parent as a container with children inside (like a groupbox or a > document) -- this is the normal use of parent in an accessible object > hierarchy > 2. Parent as something which logically groups external items, as in a > parent tree item, a menu item with a submenu, a button with a popup, or > a diagram object with children, such as in an organizational chart. This > is the concept of ARIA owns. > > I'm not sure that ARIA really differentiates between the popup and > non-popup case of owns. Owns doesn't care if the owned items are > currently visible. > > Child of sounds right, but then the inverse relation isn't there. > > - Aaron > > > David Bolter wrote: > >> Aaron Leventhal wrote: >> >> >>> We need to support the owns=[idrefs] relation, as well as hasparent=[idref]. >>> They are basically the same, but owns allows you do create the >>> definition on the owner vs. hasparent on what's owned. >>> Owns can have more than 1 item, hasparent can contain only 1 ID. It's >>> probable that hasparent will be removed before ARIA becomes final. >>> >>> Which ever is used, the user agent can expose both sides of the >>> relationship via AT-SPI and IA2. >>> >>> We need to figure out which AT-SPI relations we should use for each. >>> Here are the possibilities: >>> >>> RELATION_MEMBER_OF >>> RELATION_NODE_CHILD_OF >>> RELATION_SUBWINDOW_OF >>> RELATION_EMBEDS >>> RELATION_EMBEDDED_BY >>> RELATION_POPUP_FOR >>> RELATION_PARENT_WINDOW_OF >>> >>> Definitions of owns and haspopup here: >>> http://www.w3.org/WAI/PF/Group/adaptable/ >>> >>> >>> >> I don't have a login for this. But I did find this definition of the >> owns relation: 'The owns property defines an object as a parent of >> another document element, however the child does not appear directly in >> the subtree of the owner." >> (http://www.w3.org/TR/aria-state/) >> >> This definition makes is sound like an ancestor-of kind of relation but >> I'd like clarity here. Is there an implied containment? Or an implied >> "within subtree" (if you know what I mean)? >> >> Here is my attempt at a deductive approach based on this interpretation >> of "owns" and having re-read the at-spi docs (and after a couple of >> glasses of wine): >> >> RELATION_MEMBER_OF >> * I don't understand the at-spi defintion of this relation clearly. >> RELATION_NODE_CHILD_OF >> * possibly >> RELATION_SUBWINDOW_OF >> * possibly but i don't like that it has "window" in the name... could >> be confusing >> RELATION_EMBEDS >> * cross process definition doesn't fit. >> RELATION_EMBEDDED_BY >> * ditto >> RELATION_POPUP_FOR >> * popup is a subtype of "owns" correct? if so this doesn't seem to >> capture all of "owns" >> RELATION_PARENT_WINDOW_OF >> * ditto comment to subwindow_of relation >> >> So I'd lean towards child_of but there is no reciprocal parent_of? >> >> What about RELATION_EXTENDED? >> >> Let's hear from the guru... Bill? >> >> D >> >> >> >>> Definitions of AT-SPI relations here: >>> http://www.gnome.org/~billh/at-spi-idl/html/namespaceAccessibility.html#a215 >>> >>> >>> Opinions? >>> >>> - Aaron >>> _______________________________________________ >>> Gnome-accessibility-devel mailing list >>> [email protected] >>> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel >>> >>> >>> >> _______________________________________________ >> Gnome-accessibility-devel mailing list >> [email protected] >> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel >> >> >> > _______________________________________________ > Gnome-accessibility-devel mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel > _______________________________________________ Gnome-accessibility-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
