Comments on "An Invisible XML Modularity Proposal"

Comments on "An Invisible XML Modularity Proposal"
https://nineml.org/proposals/2026/modularity/

Requirements.

I agree with requirements 1, 2, 5, and 7.

I disagree with 3,

 It should be convenient to include all of the rules that
 are in the public interface and no others.

since this breaks one of my requirements [reqts]:

 It should be possible to independently check modules for
 completeness and consistency, so that modules can be checked
 before they are combined.

So "+include xyz.ixml" doesn't reveal what is used from that grammar,
and so the grammar using it can't be checked for completeness and
consistency without xml.ixml already being available and readable.

I disagree with 4:

 It should be possible to include any rule from a grammar.
 Ultimately, reuse should be in the hands of the author of the
 including grammar.

because this breaks two of my requirements:

 Modules should have a visible contract of use, on both the
 producer's as the user's side, so that it is obvious what each
 module uses and shares, and that if there are different
 implementations of a particular module they can be swapped in
 and out.

 The internals of a module should be protected, so that a
 module owner can change the implementation of a module, as
 long as the interface contract is maintained.

I disagree with 6

   It must, however, also be possible to redefine any nonterminal
   in the included grammar.

for the same reasons.

1.1 SHARE

"If a grammar does not have an explicit share statement, all of the
nonterminals it defines are implicitly shared."

I think I can live with this. This is the use case where you want to
split your grammar into smaller parts.

1.2 INCLUDE

I went through literally dozens of possible keywords for "use" and
"share" before settling on them. In particular I rejected "include"
because of its similarity to the one used in the C preprocessor. In
ixml modularisation the semantics are very different to those of C's
#include, and therefore could lead to misunderstanding.

1.2.2 Renaming

I understand the use case for this.

1.3 Redefinitions

As pointed out above, I am strongly opposed to this. As I see it, the
use case is to allow parameterised modules (which animals are allowed;
which table types), and I would far prefer for that to be addressed as
a requirement, use case, and explicit design, than allowing users to
just mess with modules.

Reference

[reqts] https://cwi.nl/~steven/Talks/2025/06-06-markupuk/paper.html#L112

Steven

Received on Tuesday, 7 July 2026 12:05:56 UTC