Re: [relax-ng-comment] A lightweight include mechanism

[James Clark <jjc@jclark.com>]

> The problem, if I understand it correctly, is that the nested grammar
> idiom uses the <include> mechanism with attendant copying of the
> included definitions. This is completely impractical for the XUL
> <template> - the multiplication factor would be huge.

An implementation of <include> doesn't necessarily have to copy. Its
semantics are described that way but any implementation method that produces
the same effect can be used.  For example, an implementation may load it
once and cache it. The problem is when it is included in a context where
definitions and changed or modified.  There are some cases that are easy to
handle.  For example, one common idiom is:

<grammar>
  <include href="foo.rng">
     <start>
        <ref name="xyzzy"/>
      </start>
   </include>
</grammar>

An implementation in this case can have share one copy of foo.rng for all
such <grammar> elements.  (Jing doesn't yet implement this optimization
strategy).  Allowing grammars to be shared with other kinds of modification
is also possible without appropriate implementation smarts, though it is
hard to do in general.

> What I am suggesting is a parameterized <ref> mechanism which would
> allow definitions to sandwich themselves into other definitions without
> the need for copying - a sort of pattern subroutine.
>
> 1. Define a parameterized pattern (possibly included - but only once).
> <define name="foo">
>     <parameter name="p1"/> <!-- not strictly necessary, the use of
> parameterName on a ref element is sufficient-->
>     ....
>     <ref parameterName="p1"/>
>     ....
> </define>
>
> 2. use the pattern, supplying bar as the instance of p1 to use in this
> case:
> <define name="bar">
>     ...
>     <ref name="foo">
>         <parameter name="p1">bar</parameter>
>     </ref>
>     ....
> </define>
>
> 3. the supplied parameter pattern:
> <define name="bar">
> ...
> </define>

This has been suggested many times and its a sensible thing, and I expect it
is something we will consider if we ever to a version 2.0.

However, from an implementation point of view I don't believe there is any
fundamental difference with the include.  The straightforward implementation
of such a param feature would be to expand the parameterized pattern once
for each distinct set of parameter patterns.  Avoiding such expansion faces
exactly the same problems as with the <include> case.

James