Re: Comments on "An Invisible XML Modularity Proposal"

> We aren’t talking about distributing compiled code, like Java or C#, modules where contracts about interfaces achieve binary compatibility across versions.

Well, I am! My implementation allows 

    +use xpath from https://invisiblexml.org/modules/xpath3.ixml

and that's one of my planned use cases. One of my implementations precompiles the modules into parser-ready form.

> Any iXML grammar being imported is necessarily “available right there as text”.

Well, I disagree.

> There’s nothing stopping the user from extension by copy-and-paste. All that you gain by forcing them to do extension that way is that it becomes much harder to manage evolution of the grammars.

Completely disagree. Copy and paste is always available if that's what you prefer, but ixml modularisation as I envisage it is not a macro language.

> I like the idea of a publishing an interface. Telling users: this will not change, you can rely on it, helps users be confident about what’s likely to change. But if I want to use something else from the grammar, well, “my gun, my bullet, my foot.”

If you don't like a module, rewrite it, produce a better one. But a contract is a contract.

> > I disagree with 6
> >
> >    It must, however, also be possible to redefine any nonterminal
> >    in the included grammar.
> >
> > for the same reasons.
> 
> I think this is absolutely crucial.

I disagree. The module should operate as a black box, with only the agreed-on interface being visible.

> > 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.
> 
> The semantics of “include” vary across languages: the C preprocessor, XML Schema, RELAX NG, XSLT, all have includes of one form or another.
> It’s not going to be confusing.

I think avoiding potential confusion is a good aim.

> > 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.
> 
> Well, I think we should work on requirements, use cases, and explicit designs, so we’re on the same page.

Exactly!

Steven

Received on Tuesday, 7 July 2026 13:15:33 UTC