Should XRAnchor extend XRSpace

[immersive-web]

Should XRAnchor extend XRSpace

[bialpio]

Could we achieve the same thing by making Anchors have an XRSpace attribute (“has-a” vs “is-a” relationship)? I’m not sure if there are any guidelines about API design that we should follow here.

Additionally, if we do decide on making anchors be XRSpaces / XRReferenceSpaces, we can consider extending XRSession.requestReferenceSpace() to allow for anchor creation instead of having an additional method to do so.

[thetuvix]

Anchors should definitely provide a space for coordinate transforms. I'm less sure if they should directly be spaces.

We already have cases of WebXR types such as input sources that are then composed of multiple spaces (e.g. grip space and target ray space). It seems fairly clean to run with that pattern - apps create logical objects such as anchors that can then be composed of 1 or more spaces through a "has-a" relationship.

[Manishearth]

Could we achieve the same thing by making Anchors have an XRSpace attribute (“has-a” vs “is-a” relationship)?

👍, we do something similar for input sources. Input sources have an XRSpace, they are not XRSpaces themselves.

[bialpio]

Closing the issue. Current approach seems to be to expose XRSpaces via "has-a" relationship. Please reopen if you disagree.