It is mentioned in a couple of places that AQL is not yet supporting XOR operator, although is part of the grammar - hence this [SPECQUERY-29] Support for XOR operator - openEHR JIRA.
This needs to be clarify: either support it, or remove it completely from specs (relates then to [SPECQUERY-8] Improve readability and clean up text - openEHR JIRA)
I would like to keep it (not only for the fact that Christian has implemented it in EHRbase…) 
@thomas.beale or @Seref - do you still remember why was this not specified? Any technical challenges perhaps? Otherwise I suggest we’ll go ahead an document it.
I suspect we did not have a clearly specified requirement for it.
Having a feature/capability at a lower level but not exposing it to a higher layer is common in the tech spec/design, for example, virtual machine specifications for .NET framework actually support more than what the languages are allowing the programmers do.
For the moment, we can keep it in the grammar, but remove from the specs. As use cases emerge, we can put it in. That’d be my suggestion.
I understand you concern and reasoning @Seref, but I am under the impression that keeping grammar different than the specs is confusing, both for end-users, as well as for us (editors), as it becomes unclear why we have these deviations.
Personally, I have no preference towards keeping XOR or either removing it completely. But if there are no technical limitation on implementing this, or no other strong objection, and based on the fact that is already inside (at least) EHRBase and inside the grammar, I would suggest we go ahead and fully specify it. Lets see first what others are thinking about this, at least @matijap and @bna as they have also an AQL implementation.
Personally, I never encountered one single AQL query with XOR, and since it can be written with combinations of other single boolean operators, it might not be needed at all.
I’m OK on making any changes to keep the spec consistent (remove from spec and grammar, or add spec and grammar). The AQL spec could mention that is an ‘optional’ operator, and the very basic are required: AND, OR, NOT.
The same could be for other operators like: NOR, XNOR, NAND.
I agree Pablo.
Suggest if any one vendor supports, leave it in, otherwise take it out, unless there is clear agreement that it should be on an early roadmap.
Like you I have never used XOR (might be my ignorance, of course!!).
I would probably leave it in, since it is a common logical operator, and it’s probably one line of code in the Antlr file, and a few lines of code in implementations, alongside AND, OR and NOT. Whereas if it is left out, someone will find a need the following week, and… then it’s really annoying!
I can see it being used for data quality purposes: Something must be in this path (coded_text) or in this other path (boolean), but not in both at the same time (as they could contradict each other)
As decided in the meeting of 16-Nov, XOR is removed from grammar - will appear under SPECQUERY-8.