Re: Comments on "An Invisible XML Modularity Proposal"

On Tue, Jul 7, 2026, at 09:34, Steven Pemberton wrote:
> 
> On Tuesday 07 July 2026 14:56:11 (+02:00), Graydon Saunders wrote:
>> On Tue, Jul 7, 2026, at 08:43, Norm Tovey-Walsh wrote:
>>> Steven Pemberton <steven.pemberton@cwi.nl> writes:
>>> > 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.
>>> 
>> As an habitually lightly dazed user of ixml, I would like to chime in here in support of Norm's position.
>> 
>> "include" isn't a specific behavior and it isn't even a general class of semantics; it's a concept, "use stuff from over there". How that happens is expected to be language-specific. (e.g., Schematron, where the concept gets split into "include" and "extend".)
> 
> Ha ha, and to explain it you use "use"! "use" clearly a better choice then ;-)

"Use" by itself doesn't haul in the "from over there" part.

I'm getting the impression that the crux of the disagreement is over whether the mechanism for having parts of the grammar in distinct locations works to assemble something equivalent to a single text file which is then parsed, or whether this mechanism functions by having distinct grammars which can be used together despite being parsed at different times by what might be distinct means.

I've got a strong preference for the former; if I can get at all the textual description of the grammar, needs must I can change it. If I can't do that, I have to both localize bugs ("that's not me, that's the module" vs "that is me, not the module") and then think of something sufficiently clever to fix the problem when part of the grammar is inaccessible to me. That functions to make something already difficult more difficult.

Were we to come to have large complex grammars with significant third party components in the way there are C libraries or EXPath modules, the "used together" approach is a helpful thing to have. But I don't think ixml will get there without starting out as something that's relatively easy to use and if it does get there it does no harm and perhaps avoids some if the "muster a single text file, which is parsed" mechanism and the "these are collaborating distinct grammars" mechanism do not try to be a single mechanism.

Graydon