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

[Aaron Leventhal <aaronlev moonset net>]

I will push the same solution for IA2 that we get for ATK.

But we really need Bill Haneman's opinion.

- Aaron

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