- From: C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com>
- Date: Sun, 27 Aug 2023 12:19:50 -0600
- To: graydonish@gmail.com
- Cc: Norm Tovey-Walsh <norm@saxonica.com>, public-ixml@w3.org
Point taken. I note, for example, that Relax NG (a) defines explicit terms with the required meanings, and (b) calls one of them 'notAllowed' rather than (for example) 'empty-set'. Michael Graydon <graydonish@gmail.com> writes: > On Sun, Aug 27, 2023 at 09:43:40AM -0600, C. M. Sperberg-McQueen scripsit: >> Graydon <graydonish@gmail.com> writes: >> > ∅ (U+2205 EMPTY SET) might be another character possibility. >> >> Please no. In some discussions of formal languages (at least), ∅ is >> used to denote the empty language -- that is, the language that has no >> sentences. It is not the same as the language consisting of the empty >> string '', which is often denoted ε (U+0385 GREEK SMALL LETTER EPSILON), >> as in Norm's proposal. > > I was unaware! > > That would indeed make things confusing; suggestion withdrawn. > > [snip] >> For me, part of the appeal of ixml is its relative simplicity. Adding >> keywords or symbols that do not change the expressive power of the >> language is a slippery slope. I won't say never, but I'm skeptical. > > I think "as simple as possible, but no simpler" is a supportable principle. > > Having meaningful implicit nothingness is simple in a "language rules" > sense but not simple in a "using the language" sense. It creates a > category of syntax errors which can't be reported by machine parsing > because there's nothing mechanically wrong with the syntax even when > there is a significant error in meaning. > > A rule for "No meaningful implicit nothingness" (which is how I > understand Norm's proposal) strikes me as a large gain in > utility. Such a rule need not include a standard representation of > nothingness, fundamentally it just has to require the parser to throw > an error. > > I would prefer a standard representation of nothingness, but I need the error. > > I use ixml in production to test that generated text conforms to > agreed patterns of natural language. I don't think the second time I > do this the grammar will be more effort than the code that generates > the text, but it isn't going to become trivial, either. "Making ixml > easier to use" might not be a sensible goal—grammars are not on the > list of things easy to use—but I think introducing this particular > error condition is a large gain for small cost. > > -- Graydon -- C. M. Sperberg-McQueen Black Mesa Technologies LLC http://blackmesatech.com
Received on Sunday, 27 August 2023 18:22:31 UTC