Directions of ixml
Around ixml a number of issues are being discussed:
This is completed work, but not yet officially published. It gives control over the element and attribute names used in serialisation. It is already widely implemented. See the modularisation paper (mentioned shortly) for examples
date: y, m, d.
⇒
<date><y>2025</y><m>08</m><d>06</d></date>
While
date > d: y, m, d.
⇒
<d><y>2025</y><m>08</m><d>06</d></d>
Recreate an equivalent textual document from a serialisation. 
One implementation to date, where they call it producing the "canonical" value.
See paper from XML Prague 2024: Steven Pemberton, Round-tripping Invisible XML
Allow the combination of different modules.
+uses ixml, name, s, RS from ixml.ixml;
iri from iri.ixml
+shares module
module: s, (multiuse; shares)*, ixml.
-multiuse: -"+uses", RS, uses++(-";", s).
shares: -"+shares", RS, entries.
uses: entries, RS, -"from", RS, from.
-entries: share++(-",", s).
share: @name, s.
@from: iri, s.
See paper from MarkupUK 2025: Steven Pemberton, Modular ixml
Lexical analysers are a historical artefact to enable the use of non-general parsing algorithms.
New approaches add constructs to remove the need.
Paper: van den Brand, M.G.J. et al., 2002, Disambiguation Filters for Scannerless Generalized LR Parsers.
I have an as-yet unproven conjecture that you only need to add one construct:
Alongside A*, A+, A?, add A! which means "An A may not appear here".
identifier: letter+, letter!.
This means "The longest stretch of letters you can match"
keyword: "if", letter!;
"then", letter!;
"else", letter!.
identifier: keyword!, letter+, letter!.
This means "the longest string of letters, that is not a keyword".
This is surprisingly the most contentious issue currently: how to address individual pieces of software.
There was a paper at Balisage 2022: Tomos Hillman, et al. Designing for change: Pragmas in Invisible XML as an extensibility mechanism
My view: keep it simple, and don't dictate to individual software how they wish to be directed, since by definition they will each have different needs. A pragma should be identifiable as such, and the content should be up to the addressed software.
Please join the group if you feel you have things to contribute