Should extension specs be allowed to override required owned elements with subclasses?

[joanmarie]

According to a note at https://w3c.github.io/aria/#mustContain:

An element with a subclass role of the 'required owned element' does not fulfill this requirement. For example, the list role requires ownership of an element using either the listitem or group role. Although the group role is the superclass of row, adding a owned element with a role of row will not fulfill the requirement that list must own a listitem or a group.

Do we want to adhere to this for extension specs? If we don't, then we can come up with the appropriate language and fix w3c/dpub-aria#15 automagically. If we do, then we need to convey that to Publishing folks so that they can solve it on their end (e.g. by creating their own role a la doc-biblioentrylist).

[jnurthen]

If the current statement were not there there would be impact on the following role

• combobox would also allow searchbox, treegrid and alertdialog as children
• list,menu,menubar, tree would also allow intemediate nodes of anything which is a subclass of group (row,toolbar,select(abstract) and by extension all form fields which subclass select)
• listbox would allow treeitem children
• radiogroup would allow menuitemradio children

My conclusion for this is that we cannot allow subclasses to fulfill the required owned element requirement.

[jnurthen]

A further thought is that perhaps we could allow subclass children to fulfill required owned element requirement iff they ONLY subclass a single role.
If this were the rule then the only impacts would be the following

• combobox would also allow searchbox children
• list,menu,menubar, tree would also allow intemediate nodes of toolbar

So we could potentially resolve this issue by modifying the inheritance for toolbar and searchbox AND modify the note to allow subclass roles to fulfill the requirement so long as they only subclass a single role.

[joanmarie]

If I understand you correctly, I don't think this is a good idea.

1. We periodically mess with the subclasses. What if we make this change and then decide to add multiple inheritance to a particular role? By side effect, we'd be changing the valid required owned elements. This seems potentially breaky.

2. It also seems potentially hacky. Let's say that, for some reason which has nothing to do with the problem at hand, we decide that treeitem should no longer subclass option. Now it only (immediately) subclasses a single role. Wouldn't that make treeitem a valid owned element for list??

3. It also strikes me as a bit confusing. What's so special about only having a single (immediate) superclass?

[jnurthen]

1. Yep
2. Yep
3. Single superclass seems like it should map to a very similar platform role. Multiple superclasses makes that much less likely. But Yep - agree it is confusing.

I'm just really trying to look at all the possible options we have on the table. Happy to reject any of them.

[rdeltour]

I'm just really trying to look at all the possible options we have on the table.

For the sake of completeness, here are a couple other options:

• allow subclass children only if they're defined in extension specs
• define a new kind of relationship in 5.1 "Relationships Between Concepts", for instance a "specialized subclass role", which would represent the roles that are subclasses and could be used wherever their superclass is allowed.

My take:

• I don't like the first option, as it's not super resilient and kinda introduce a dependence on spec editing and organization (what if some extension roles become integrated in the core spec at some point?).
• the second option w/b worth being further explored.

[pkra]

@rdeltour this topic came up on the last telco, see https://www.w3.org/2019/10/03-aria-minutes.html#item06

[jnurthen]

This issue was discussed in a meeting.

• No actions or resolutions

View the transcript

[Should extension specs be allowed to override required owned elements with subclasses?](#1056
joanie: we have to come up with a solution for dpub.
... maybe the group has (new) ideas.
jnurthen: I pursued the idea of changing the taxonomy.
... it's larg-ish task but not impossible.
... group and tree-item.
... are probably the main ones, group the biggest.
... we'd essentially need a different/abstract grouping role.
... but won't solve dpub problm.
... if people could look at last item (repeated content), please do.
Aaron: I think we need a high-level discussion rather than my PR.