Hi, I agree with the naming, we should go with UniAST to be more consistent with XS.
To answer your questions:
- The client-side API is required in Cristal, but not necessarily useful in XS. We may want to integrate Cristal in projects where there isn’t a server to render macros, and thus macros should work entirely client-side.
- Good point, there are capabilities that are explicitly missing in UniAST. For instance, macros cannot transform their parent content, as this is a non-goal we decided when designing the new macros system. You can find the full API here: https://cristal.xwiki.org/xwiki/bin/view/Documentation/Extensions/Macros. Macros currently can’t be syntax-specific, but this is something we might want to come up with in the future ; note that it’s not related to UniAST itself, as macros are a separate concept. Also, some features are explicitly missing too (such as character-level features) as, as I stated, features that are not yet available in the target WYSIWYG editors are not represented in UniAST for now.
- I only discussed with @mleduc, as I wasn’t familiar with XDOM at all at the time UniAST was designed. Discussing further with @mflorea, some shortcomings appeared and it’s definitely planned to take a closer look at XDOM to fill in some missing capabilities in UniAST.
There should definitely have been some discussion around it on the forum, alas I was unfamiliar with this process when I started designing UniAST. This is on me, and why I write proposals for all major changes now (e.g. removing client-side macros AST).