You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Elsewhere @azaroth42 has said, "I think multiple selections should be at the SpecificResource [locator] level, the same way as we can have multiple targets in an Annotation." I would suggest that this is dependent on the answer to [issue #24]. If ERS is a valid Selector, then the multi Selector seems okay. But if ERS is not a valid type of Selector, then multi Selector is also not a Selector, and we would need to fall back on the multi-locator approach previously proposed.
I am not sure the relation with #24 is so clear cut. Of course, if the ERS is not a valid Selector, then we have a problem with MultiSelector, too, which relies on it. However, even if ERS is a valid Selector, one could think of dumping a MultiSelector in favor of multiple locators.
That being said, it becomes also a convenience question. The Locator's usage/implementation may be simpler if everything is one locator; otherwise we are forced to define higher level notions on how locators are used (this is not a problem for WA, but we would have to do something extra here, if only by taking over more from WA). Ie, I prefer keeping the local structure, but, at the end of the day, end users as well as implementers may have to decide...
(Taken from @tcole3’s comment)
The text was updated successfully, but these errors were encountered: