Invisible XML: Standards Update
Steven Pemberton, CWI, Amsterdam
Invisible XML [ixml] has had a stable specification since 2022, there are currently a half dozen implementations, and typically a dozen presentations per year have recently been given at conferences. At the beginning of 2026 the first International Symposium on Invisible XML was held [sym], with 14 presentations and 40 or so attendees. Meanwhile there is a working group [wg] developing the language further.
This talk gives a brief overview of the topics and issues currently being considered within the community on the route to the next version.
Keywords: markup, invisible xml, ixml, notation design, parsing, standards
This is completed work; already widely implemented; not yet officially published.
Allows a different name from the rule name on serialisation. Without renaming, you get
date: y, m, d.
⇒
<date><y>2025</y><m>08</m><d>06</d></date>
While using renaming gives a different serialisation:
date > d: y, m, d.
⇒
<d><y>2025</y><m>08</m><d>06</d></d>
Modularisation allows splitting grammars into smaller more manageable parts:
Can be done by preprocessor: a processed modularised grammar can still be used by implementations that don't support modularisation.
Currently two proposals. Here's one:
+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.
Round tripping is defined as as "producing a document that would produce the same output".
It is done by transforming grammars. Grammar g is the original.
Grammar g' is a transformed version that produces an equivalent
document to the original one.
Transforming g' using the same transformation process to create grammar g'' will also produce the identical output, but with far simpler use of the ixml serialiser.
Ambiguity is accepted in ixml: one of the ambiguous parses is serialised, with a warning.
Disadvantages of ambiguous grammars:
Approaches to dealing with ambiguity:
One current proposal is to add a construct "!":
For example,
identifier: letter+, letter!.
means "The longest stretch of letters that can be matched".
keyword: "if", letter!;
"then", letter!;
"else", letter!.
identifier: keyword!, letter+, letter!.
means: an identifier is the longest string of letters that is not a keyword".
One proposal: things that look like attributes in the serialisation and
begin with the characters xmlns should be interpreted as namespace
declarations.
For implementations that produce textual output, this adds no extra processing.
For implementations that go directly to an XML internal form, the namespace declarations have to be recognised and handled appropriately, as they are in XML processors.
Example
html: xhtml-ns, head, body. @xhtml-ns>xmlns: +"http://www.w3.org/1999/xhtml".
which would give
<html xmlns='http://www.w3.org/1999/xhtml'>
A problem for beginners coming to ixml is that they may have internalised idioms from similar systems that work differently from ixml, such as greedy matching from regular expressions, which is different in grammars.
An option would be to introduce a separate notation to specify the longest possible stretch, for example
["a"-"z"]>>
which then for consistency would require a similar construct for separated repeats:
["a"-"z"]>>(",", s?)
However, as already seen, the ! construct would already cover this use case.
Some grammar systems allow the specification of numbered repeats, for instance "zero or more up to 6 letters". As an example ABNF [abnf] allows
3 digit
to specify exactly 3 digits,
1*4 digit
to specify 1-4 digits, and so on.
There are very few grammars that requires such a notation, though it would be easy to transform a grammar using such a construct into one not using it.
This is surprisingly a contentious issue: how to address individual pieces of software from a grammar.
For instance, XML has the PI:
<?xml-stylesheet type="text/xsl" href="style.xsl"?>
These are typically a type of comment: they don't alter the semantics of the language, but instruct a mode of operation to the processor.
Does the input need to tell the software which version of the language it is using, and if it doesn't say, which version should be assumed?
The design of the first version of ixml itself went through several iterations, and had small-scale user testing before it ended up as version 1.0.
The next version, 1.1, or 2.0, whatever it will be called, has many, sometimes apparently conflicting, requirements that need to be resolved and meshed well together.
There is a full paper for those interested in more detail.