As things are at the moment, an implementation can avoid rereading by
noticing when it gets
a) an externalRef to a grammar, or
b) a grammar whose only child is an include whose only child is a start
without a name attribute, or
c) a grammar element containing an empty include element and a start
without a name attribute
It keeps a table mapping URIs to such grammars. When it encounters a case
of type (b) or (c), it simply evaluates the content of the <start> in the
context of the saved grammar.
I'm not clear what you perceive the problem to be with the current state of
things. The above optimization is not hard to implement; the only problem
is that an implementor may not know about it, or may not think it worth
implementing.
Is it that you think
<grammar>
<include href="...">
<start>
<ref name="..."/>
</start>
</include>
</grammar>
is too verbose? One possibility is to introduce a construct:
<withGrammar href="u"> p </withGrammar>
equivalent to
<grammar><include href="u"><start>p</start></include></grammar>
or
<grammar><include href="u"/><start>p</start></grammar>
depending on whether u already has a <start> or not.
Then you can say, eg
<withGrammar name="x.rng">
<choice>
<ref name="foo"/>
<ref name="bar"/>
</choice>
</withGrammar>
--On 07 July 2001 10:56 +0900 Murata Makoto <> wrote:
> James Clark wrote:
>
>> Is the issue here simply whether we want a shorthand for
> ...
>> ?
>
> I do not have any good ideas. But here are some questions.
>
> - How do we avoid rereading?
>
> - Does it make sense to introduce two constructs? One is for including
> external patterns without collisions of named patterns, and the other
> is for referencing named patterns in already-included patterns.
>
> Cheers,
>
> Makoto
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to:
>
>
