- From: Steven Pemberton <steven.pemberton@cwi.nl>
- Date: Wed, 29 Nov 2023 23:34:06 +0000
- To: "C. M. Sperberg-McQueen" <cmsmcq@blackmesatech.com>, Gunther Rademacher <grd@gmx.net>
- Cc: public-ixml@w3.org
> Of these, GR's formulation is the most compact. but doesn't allow a...b Steven > > Michael > > > Gunther Rademacher <grd@gmx.net> writes: > > > Sorry for jumping in, but it should be > > > > @name: namestart, (namefollower ** ('.'?)). > > -namestart: ["_"; L]. > > -namefollower: namestart; ["-·‿⁀"; Nd; Mn]. > > > > Of the variants proposed below, the first one still allows a period at the end > > of a name, while the second one allows more than one namefollower only > > if preceded by a period. > > > > Best regards > > Gunther > > > > Gesendet: Dienstag, 28. November 2023 um 17:51 Uhr > > Von: "C. M. Sperberg-McQueen" <cmsmcq@blackmesatech.com> > > An: public-ixml@w3.org > > Betreff: Proposal to change definition of 'name' (forbid final .) > > It was observed on this morning's CG call that allowing names like > > > > foo. > > > > causes some difficulties for recursive-descent parsers (and any other > > parser with limited lookahead, perhaps), which are out of all proportion > > to the advantages, if any. > > > > This is to propose a simple fix: continue to allow . to occur in names, > > but forbid it to appear at the end of a name. Since no one on the call > > remembered ever seeing an XML name with a final full stop outside of a > > test suite, this did not seem likely to be a painful restriction. > > > > Concretely, delete the current definitions: > > > > @name: namestart, namefollower*. > > -namestart: ["_"; L]. > > -namefollower: namestart; ["-.·‿⁀"; Nd; Mn]. > > > > and replace them with: > > > > @name: namestart, namefollower*, ('.', namefollower*)*. > > -namestart: ["_"; L]. > > -namefollower: namestart; ["-·‿⁀"; Nd; Mn]. > > > > or alternatively: > > > > @name: namestart, (namefollower ** '.'). > > -namestart: ["_"; L]. > > -namefollower: namestart; ["-·‿⁀"; Nd; Mn]. > > > > Comments and discussion welcome. (And it occurs to me that someone > > should check to make sure that this does actually address the LL(1) > > issue.) > > > > Michael > >
Received on Wednesday, 29 November 2023 23:34:17 UTC