Re: Comments on "An Invisible XML Modularity Proposal"

Steven Pemberton <steven.pemberton@cwi.nl> writes:
> 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.

That’s interesting, but it seems a little unnecessary to me.

> 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.

Yes. And I think you’re wrong about that :-)

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

Any iXML grammar being imported is necessarily “available right there as text”. 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.

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.”

> 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.

> 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.

> 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.

--
Norm Tovey-Walsh
CEO, Saxonica

Received on Tuesday, 7 July 2026 12:43:24 UTC