One "Equal" expression is enough. Your RHS fact should be another vocabulary item. In case of XML type a proper path will pull all values one by one and cause multiple evaluations and respectively firing an action if there's a match. The key to remember: BRE is a pattern matching engine.
The vocabulary is just a convenient alias for the fact definition. Let's say you create an XML file with the following structure:
<options>
<value>A</value>
<value>B</value>
<value>C</value>
</options>
Define a vocabulary for this fact as Name: PossibleValues XPath Selector: /options/value XPath Field: .
Then defining a rule as IF currentValue == PossibleValues will cause three condition evaluations as the RHS yields three facts into the working memory. Consequently, only those that were true will fire a rule (Action). Compare this to the default definition BRE creates when you pick a node from the XML schema which will only assert one (first) fact:
XPath Selector: /options/ XPath Field: value
(namespaces omitted for brevity)
At runtime pass this XML document as an argument to the BRE (whether in the orchestration or in .Net component depending on BRE invocation context). At design time for testing you have to implement Fact Creator component (implements IFactCreator) to provide an instance of required arguments.
Long-term facts (like the one in the question) are better managed using custom fact retrievers. Fact retriever is a .Net component that implements IFactRetriever. See the documentation for details. Inside fact retriever implementation load XML (from disk) and assert it into the working memory as TypedXmlDocument.