- 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