Hello Ludovic,
Thanks for your thorough answer!
First of all let me clarify that I’m not questioning whether to use a Wiki or not - we’re already using XWiki for a while, missed a Wiki severely before and in general are quite happy with it, such that I signed a silver support contract to support Xwiki development.
It’s just the competition you’re writing about, between XWiki on one side and rich tables or documents from other / foreign sources as well as legacy documents on the other side.
So it really is just about either how to integrate those different documentation sources best or about usage concepts - how to avoid or lessen the need of better integration by using different conventions.
So all of our internal “real” documentation is being created in XWiki only. Its editing and formatting capabilities are fine and I assume will get increasingly better especially as the macro inline editing features in the WYSIWYG editor continue to be improved.
We currently hit limitations there in case of pretty complex tables which we often use as an easy way to manage overview tables or to do polls and the like. Another case is estimation sheets for projects where we actually do need formulas in the table, which would be much more difficult and less flexible to do in XWiki, even using custom macros. Using a spreadsheet application you can just create a table, add some formulas and off you go.
In other cases the tables are just very complex such that you simply do not really want to edit it in a browser if it can be avoided. My comment about editing copies of the files using desktop applications was less about offline editability and more about usability / user friendliness. As good as online office solutions as CODE and possibly OnlyOffice (which I’ve not tested so far) are, a native desktop application still providers better performance and usability.
However, much of this probably could be solved by using XWikis OnlyOffice integration, which I will have a look at in near future - it sound like the most promising way for us to go for now.
I also already noticed that integration could be improved on the Nextcloud side - that’s why I also posted my original thoughts in their forum, however so far I didn’t have a single answer there. Possibly my original post was much too long, tough anyway the support and feedback in your forum is much better than in Nextcloud’s. So thumbs up, the quick reactions from @vmassol and eg. @mflorea were a significant reason for me to stay with XWiki and later actually sign my support contract.
Unfortunately, Nextcloud does not allow direct links to a document’s editing or browsing view for logged-in users. It does so, however, with anonymous public sharing links, which normally is not what I want to do.
(That was actually what I was referring to in my original post, it wasn’t my intention to link from one office document to another within Nextcloud - I more thought about adding links to office documents into the Wiki, which after a click would open the document (or PDF, or whatever) directly in edit mode. It would allow more seamless crosslinking that is possible at the moment.)
I opened a Nextcloud feature request for this last year, but there has not been any action or progress since then: Allow "Direct Editing" Link Without Public Sharing · Issue #12470 · nextcloud/server · GitHub
Concerning OnlyOffice: What was keeping me back was for one, that OnlyOffice is based on OfficeOpen XML while XWiki’s Office Server, also used for rendering document previews and stuff is the OpenDocument-based LibreOffice, so I will have to see if this causes any compatibility problems or if I’m fearing issues here which just do not exist.
Very few of our tables will not be usable this way, they are LibreOffice Calc only and just plainly do not work in Excel, and so most likely also not in OnlyOffice - but those are rare exceptions.
That being said, I’ll try it if it’s the best option we have at the moment. As far as I see, I can get a unlimited usage license for the OnlyOffice connector with a one-time payment?
As a personal aspect, the development of CODE / LibreOffice online is “more open” than the OnlyOffice development, which I personally prefer. On the other hand of course I also fully understand that implementing an online office integration is much work and takes much effort, and as such you cannot offer connectors for every immaginable foreign software package out there.
Also probably Xwiki is too rarely used for Collabora to implement the integration from their side, though maybe it might be an idea to talk with them about it - maybe if you also find additional sponsors among your customers. (Nextcloud and Collabora partnered somehow and made quite some fuss around that, publicity wise.) I also already asked your support colleagues about possible sponsoring models in general - as, as a 7-person-company, our possibilities there are limited - and am eagerly waiting for a reply. (This question was not related to CODE integration, though, as sponsoring this probably would exceed our possibilities in any case…)
I’m not trying to do.
However for example we have an icon collection consisting of thousands of icon files, which should probably stay in Nextcloud. Also we have foreign documentation of a standard we’re working with, which consists of hundreds (!) of PDF files distributed over some dozend directories - that’s probably also something where integration into XWiki does not make too much sense, or how would you takle that?
So there’s a bunch of data comparable to this, plus the stuff already mentioned above.
Meanwhile I tried that, but it only sort-of works. I can attach XWiki to Nextcloud as an external WebDAV storage, and it’s mounted and presented as a new folder in the Nextcloud interface. I can access it, but many operations lead to an Exception being logged in Nextcloud, in which case I’m redirected to the root folder. This issue is also known on the Nextcloud side, but I cannot currently find the issue number. Also indexing the XWiki contents does not work probably due to the same problem - Nextcloud starts indexing the remote storage and soon terminates this process with an Exception. However probably it’s no big deal. As I do not assume that Nextcloud will do anything about this anytime soon, I may try to have a look at this myself, even though I’m probably also lacking the time…
Probably more important is that the performance is not really good, so not sure how practically usable this approach would be. Nevertheless attachment focused WebDAV access sounds very interesting. It probably even does not hurt to have the occasional Wiki page data floating around as text files, as it’s at the moment. What’s more problematic is that much of the content is exposed redundantly via multiple pathes. (I’m only talking about the “spaces” folder, it’s obvious that content is presented redundantly through the other special folders.)
However from my point of view the mapping from XWiki spaces to folders with files fits quite well, at least more or less. Why do you think its difficult to represent XWiki’s content as folders and files? Besides the redundant pathes my impression was that it seems to look quite straight-forward the way it’s done by the WebDAV server extension. Or are you referring to the reason those redundant pathes exist at all?
Another idea: Do you think a WebDAV client extension for XWiki would be doable, which would expose all files in a WebDAV directory as “virtual attachments” in a given XWiki page?
As I wrote I also noticed the missing viewer / editor access API (Allow "Direct Editing" Link Without Public Sharing · Issue #12470 · nextcloud/server · GitHub which I opened last year), but I’m currently pursuing this route. I’m adding links to Nextcloud to my XWiki articles and try to annotate them with relevant key words so the links are also found if being searched for. I also installed the Nextcloud README.md app (README.md - Apps - App Store - Nextcloud, you should wait for the next release which fixed a bunch of significant bugs in 1.0.4 which I reported after testing it) and am adding lots of HEADER.md and README.md files to my Nextcloud folders which point back to XWiki, wherever appropriate.
I replicated the same basic hierarchical structure in both XWiki and Nextcloud, such that my documentation and documents is categorized in similar ways in both systems.
Still it’s annoying not to be able to reference documents in XWiki in a way which seamlessly opens them in edit or viewer mode. 
I would imagine this to be a great enhancement for this use case - especially as it’s already supported for public share links. Unfortunately, there’s not much XWiki can do in this case, I assume.
Concerning ActivityPub, I’ve read that it exists, but have never tried it so far. I could be an interesting route to pursue, but I’d hope that it actually fulfills its promises. When I tried End-to-end-Encryption - which was announced as a big feature in NextCloud 13 - it was a hard landing because even with Nextcloud 15 it simply still does not work and is not usable - and there is no timeline, when it will be and no official reaction from the Nextcloud devs, unfortunately. (Also see Status End2End-Encryption in NextCloud? - #3 by GOhrner - end-to-end-encryption - Nextcloud community and related posts concerning this.) So I’m a bit careful now whenever it comes to more advanced features Nextcloud is supposed to support… 
Regards,
Gunter