While I responded to the question on the group, I've also come across a different interpretation of the graph, and I also think the answer deserves a bit wider audience. Assume that you have the following documents registered in an XDS Registry:
Here is one interpretation of the graph:
The original document was addended 3 times (by AppendDocument1, 2 and 3). Two of the Addenda were replaced by subsequent versions (AppendDocument11 replacing AppendDocument1, and AppendDocument31 replacing AppendDocument31). Without arguing the potential for this occuring, the querant asks:
Is there a way, given any of these documents, to query for all of the relevant documents associated with it.
Fortunately, under this interpretation there is. Each addenda is to the original document, and would maintain an APND relationship back to the original document, and so could be obtained by calling the GetRelatedDocuments query on the Original Document.
There is another interpretation of this graph:
This is one where AppendDocument11 and AppendDocument31 append to AppendDocument1 and AppendDocument3 respectively. In this case, there is no query, because what you are asking for is the "closure" of the APND relationship to be queried for. There's no simple solution for computing the closure, and so, there is no query to support it.
Does it make sense in this case, to addend an addenda? I don't think so, and XDS remains quiet on this idea.
Now, if instead, AppendDocument3 and AppendDocument31 had instead been ReplaceDocument11 and ReplaceDocument111, the next question would be: Could you get to the entire document chain. Again, because you are looking for closure over the RPLC association, the answer again is no, there is no single query to support it.
So, my rewording of the question to IT Infrastructure is this: Should there be a query created, say "GetDocumentHistory" that gets all documents in an APND, RPLC, XFRM or XFRM_RPLC relationship and the closure over all those relationships to discover the complete history of a document (that could be executed from any document in the tree). It remains to be seen whether a Change Proposal will be submitted on this topic.
I wouldn't be hugely in favor of it for one main reason: The functionality exists in XDS today to get the history WHEN you need it through one or more queries in a deterministic fashion. In a well implemented systems with what I think are good policies (e.g., don't allow people to addend and addenda), the need to use those calls should be infrequent. The use case; as I see it for the main functions supported by an XDS registry for HIE is very limited for "GetDocumentHistory". I see no reason to add that complexity until there is a better use case for it.
Note: I can imagine a better use case, which is to compute metrics over documentation tree complexity in an HIE (an operational measure that might be useful). But for that case, I would see this not as a CP, but as a profile proposal for an additional query (or queries) to support computing this and other operational HIE metrics efficiently. And if I wanted the debate to really get interesting, I'd ask someone to show me the operational quality measures that they want, and what evidence base is for their use.