> Conceptually, we include an external grammar once (without name
> collisions) and then reference to more than one named patterns in
> the external grammar. Ideally, the syntax should directly reflect
> this semantics.
I believe my <withGrammar> idea does.
> Here is a strawman proposal. Rather than
>
> ...
> <withGrammar href="u"> <ref name="p1"/> </withGrammar>
> ...
> <withGrammar href="u"> <ref name="p2"/> </withGrammar>
> ...
<withGrammar> is not restricted to contain a single ref, it can contain any
pattern, eg
<withGrammar href="u">
...
<ref name="p1"/>
...
<ref name="p2"/>
...
</withGrammar>
>
> How about
>
> <div withGrammar="u">
> ...
> <externalRef name="p1"/>
> ...
> <externalRef name="p2"/>
> ...
> </div>
>
> ?
I see two problems with this:
1) externalRef is currently used to reference an arbitrary pattern not just
a grammar. Using a single element name for two significantly different
things:
a) referencing an arbitrary external pattern, without regard for its
internal structure
b) referencing a named pattern in external grammar
seems not a good idea to me. I believe we will need two separate elements.
I think it's going to be hard to find two names that won't be confused.
2) It seems like you are making withGrammar an inherited attribute (like
datatypeLibrary). In the simple form, we would end up with the inheritance
resolved:
<externalRef name="x" withGrammar="u"/>
With an inherited attribute it is not significant which ancestor the
attribute is specified on. This is not reflecting the intended semantic of
including the grammar once.
I believe the <withGrammar> proposal better reflects the intended semantic.
<withGrammar> signals the loading of an external grammar. <ref> references
a named definition in the in-scope grammar whether brought into scope by
<withGrammar> or by <grammar>. We don't need a new way of referencing
named definitions, just a new way of bringing a grammar into scope.
James
