UML constraint {xor} between two associations

I am currently struggeling with contraints in UML. Considering the following example:

The class A have an association to the class B and an association to the class C. Both associations are bidirectional. The Class A can have exactly one instance of B or one instance of C, but not B and C at the same time. In the other direction, B can have only one instance of A, and C can have 0..* instances of A.

I tried to solve this problem with an {XOR} constraint, which is described here https://www.uml-diagrams.org/constraint.html. Unfortunately, there are few examples that can be used as a guidance.
Here an example of my solution:

Does the solution correctly represents the described example?

UML graphics are good for many things, but there comes a point when textual expressions are needed; hence OCL constraints. IMHO the "xor" is an attempt to push graphics beyond what is sensible. Even if you manage to use it correctly, will your users or tools do likewise? Use an OCL constraint. I'm far from convinced that the exactly 1 multiplicity for a B is redefined by the "xor". I think you need 0..1 and then you really do need OCL.

context A
inv AxorB: self.B->size() + self.C->size() = 1

Your diagram is inconsistent. The multiplicities specify that every A is connected to a B and a C, but the constraint specifies that every A is connected to a B or a C (exclusively).

The multiplicities on the side of B and C should be 0..1 instead of 1.

A constraint may further restrict the links, but a constraint will never reduce the restrictions imposed by the multiplicities.

I would advise to draw the constraint a bit more to the right, so that it is more clear that the constraint applies to the right hand sides of the associations.

Further remarks:

• The {xor} notation is mentioned in the UML specifications, but not well defined. If you want to unambiguous, you might use OCL instead (see Ed's answer).
• In your diagram, the navigabilities are undefined. To indicate that the associations are bidirectional, you could add arrowheads on both sides of every association (see Christophe's answer).

As drawn, B and C are 100% orthogonal, but it is often the case that alternate functionalities also share some abstract commonalities, so it might be better for B and C to both extend the abstract BorC that provides the shared functionality. Then A just has a relatively simple regular bidirectional relationship with the abstract BorC.