- From: C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com>
- Date: Tue, 12 Apr 2022 11:27:09 -0600
- To: Tom Hillman <tom@expertml.com>
- Cc: public-ixml@w3.org
Tom Hillman writes:
> Michael said earlier that he had an idea about how to formulate a
> grammar with optional, non-empty prolog(ue)s, but if we allow a choice
> of (optional) prolog types (e.g. version and namespace declarations),
> I'd be interested to see what that looks like...
> Perhaps
> ixml: s, prolog?, rule+RS, s.
> prolog: prologChild+RS.
> -prologChild: version; nsdecl.
>
> but this would then allow
>
> • multiple version declarations
> • version declarations not at the start of the prolog
True.
> Alternatively:
> ixml: s, prolog?, rule+RS, s.
> prolog: version, RS, nsdecl*RS; (version, RS)?, nsdecl+RS.
> would be OK-ish for now, but scales horribly should there be another
> candidate member for the prolog.
I think the second refernce to 'version' is redundant; unless I'm
mistaken the same language is accepted by the slightly simpler rule
prolog: version, RS, nsdecl*RS; nsdecl+RS.
I assume that the things that will feel like going in a prolog will all
be declarations of one kind or another. The version declaration does
feel as if it should come first, but the other things I can think of as
candidates for a prolog are not constrained that way, so your idea of
'prologChild' would work:
prolog: version, RS, decl*RS; decl+RS.
or making 'prolog' a little simpler by factoring out as much detail as
possible into other nonterminals:
prolog: version-info, declarations?; declarations.
-version-info: version, RS.
-declarations: declaration+RS.
> ..., maybe allowing an empty prolog isn't terrible?
I think you're right, it's not terrible.
Michael
--
C. M. Sperberg-McQueen
Black Mesa Technologies LLC
http://blackmesatech.com
Received on Tuesday, 12 April 2022 17:27:27 UTC