Re: [g-a-devel] How to imlement ARIA's owns and hasparent in ATK (which relations)

[Aaron Leventhal <aaronlev moonset net>]

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
> > Gnome-accessibility-devel gnome org
> > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
> >   
> >     
>
> _______________________________________________
> Gnome-accessibility-devel mailing list
> Gnome-accessibility-devel gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
>
>